CWE-94
Allowed-with-ReviewImproper Control of Generation of Code ('Code Injection')
Abstraction: Base · Status: Draft
The product constructs all or part of a code segment using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the syntax or behavior of the intended code segment.
8401 vulnerabilities reference this CWE, most recent first.
GHSA-6JR9-5GR3-C64F
Vulnerability from github – Published: 2022-05-14 01:32 – Updated: 2022-05-14 01:32Microsoft Windows XP SP2 and SP3 and Server 2003 SP2 do not properly handle OLE objects in memory, which allows remote attackers to execute arbitrary code via a crafted object in a file, aka "OLE Property Vulnerability."
{
"affected": [],
"aliases": [
"CVE-2011-3400"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2011-12-14T00:55:00Z",
"severity": "HIGH"
},
"details": "Microsoft Windows XP SP2 and SP3 and Server 2003 SP2 do not properly handle OLE objects in memory, which allows remote attackers to execute arbitrary code via a crafted object in a file, aka \"OLE Property Vulnerability.\"",
"id": "GHSA-6jr9-5gr3-c64f",
"modified": "2022-05-14T01:32:14Z",
"published": "2022-05-14T01:32:14Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2011-3400"
},
{
"type": "WEB",
"url": "https://docs.microsoft.com/en-us/security-updates/securitybulletins/2011/ms11-093"
},
{
"type": "WEB",
"url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A14668"
},
{
"type": "WEB",
"url": "http://www.us-cert.gov/cas/techalerts/TA11-347A.html"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-6JRP-2CPP-FPM4
Vulnerability from github – Published: 2026-07-17 21:31 – Updated: 2026-07-17 21:31IBM Langflow OSS 1.0.0 through 1.10.0 contain a critical remote code execution vulnerability in the code validation API endpoint. The POST /api/v1/validate/code endpoint accepts user-supplied Python code and executes it directly using Python's built-in exec() function without sandboxing, input validation, or privilege restrictions, enabling any authenticated user to execute arbitrary system commands with the full privileges of the Langflow server process.
{
"affected": [],
"aliases": [
"CVE-2026-8481"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-17T20:17:30Z",
"severity": "CRITICAL"
},
"details": "IBM Langflow OSS 1.0.0 through 1.10.0 contain a critical remote code execution vulnerability in the code validation API endpoint.\u00a0The POST /api/v1/validate/code endpoint accepts user-supplied Python code and executes it directly using Python\u0027s built-in exec() function without sandboxing, input validation, or privilege restrictions, enabling any authenticated user to execute arbitrary system commands with the full privileges of the Langflow server process.",
"id": "GHSA-6jrp-2cpp-fpm4",
"modified": "2026-07-17T21:31:45Z",
"published": "2026-07-17T21:31:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-8481"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/7278923"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-6JVF-R79G-H3F2
Vulnerability from github – Published: 2022-05-02 03:45 – Updated: 2025-04-09 04:15Argument injection vulnerability in (1) src/content/js/connection/sftp.js and (2) src/content/js/connection/controlSocket.js.in in FireFTP Extension 1.0.5 for Firefox allows remote authenticated SFTP users to cause victims to alter permissions, delete, download, or move the wrong file via a filename containing " (double quotes), which is not properly filtered or encoded when FireFTP constructs the command to send to psftp.exe.
{
"affected": [],
"aliases": [
"CVE-2009-3478"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2009-09-29T23:30:00Z",
"severity": "MODERATE"
},
"details": "Argument injection vulnerability in (1) src/content/js/connection/sftp.js and (2) src/content/js/connection/controlSocket.js.in in FireFTP Extension 1.0.5 for Firefox allows remote authenticated SFTP users to cause victims to alter permissions, delete, download, or move the wrong file via a filename containing \" (double quotes), which is not properly filtered or encoded when FireFTP constructs the command to send to psftp.exe.",
"id": "GHSA-6jvf-r79g-h3f2",
"modified": "2025-04-09T04:15:00Z",
"published": "2022-05-02T03:45:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2009-3478"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/36860"
},
{
"type": "WEB",
"url": "http://vuln.sg/fireftp105-en.html"
},
{
"type": "WEB",
"url": "http://www.mozdev.org/source/browse/fireftp/src/content/js/connection/controlSocket.js.in.diff?r1=1.74%3Br2=1.75%3Bf=h"
},
{
"type": "WEB",
"url": "http://www.mozdev.org/source/browse/fireftp/src/content/js/connection/controlSocket.js.in.diff?r1=1.74;r2=1.75;f=h"
},
{
"type": "WEB",
"url": "http://www.mozdev.org/source/browse/fireftp/src/content/js/connection/controlSocket.js.in.diff?r1=1.75%3Br2=1.76%3Bf=h"
},
{
"type": "WEB",
"url": "http://www.mozdev.org/source/browse/fireftp/src/content/js/connection/controlSocket.js.in.diff?r1=1.75;r2=1.76;f=h"
},
{
"type": "WEB",
"url": "http://www.mozdev.org/source/browse/fireftp/src/content/js/connection/sftp.js.diff?r1=1.8%3Br2=1.9%3Bf=h"
},
{
"type": "WEB",
"url": "http://www.mozdev.org/source/browse/fireftp/src/content/js/connection/sftp.js.diff?r1=1.8;r2=1.9;f=h"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/36536"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-6JVG-HP25-42F6
Vulnerability from github – Published: 2024-03-01 06:33 – Updated: 2024-03-01 16:57Nteract v.0.28.0 was discovered to contain a remote code execution (RCE) vulnerability via the Markdown link.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "nteract"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "0.28.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-22891"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": true,
"github_reviewed_at": "2024-03-01T16:57:12Z",
"nvd_published_at": "2024-03-01T06:15:48Z",
"severity": "MODERATE"
},
"details": "Nteract v.0.28.0 was discovered to contain a remote code execution (RCE) vulnerability via the Markdown link.",
"id": "GHSA-6jvg-hp25-42f6",
"modified": "2024-03-01T16:57:12Z",
"published": "2024-03-01T06:33:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-22891"
},
{
"type": "WEB",
"url": "https://github.com/EQSTLab/PoC/tree/main/2024/RCE/CVE-2024-22891"
},
{
"type": "PACKAGE",
"url": "https://github.com/nteract/nteract"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "Nteract Remote Code Execution vulnerability"
}
GHSA-6JVJ-64FF-4P62
Vulnerability from github – Published: 2022-05-02 03:48 – Updated: 2022-05-02 03:48Static code injection vulnerability in RunCMS 2M1 allows remote authenticated administrators to execute arbitrary PHP code via the "Filter/Banning" feature, as demonstrated by modifying modules/system/cache/bademails.php using the "Prohibited: Emails" action, and other unspecified filters.
{
"affected": [],
"aliases": [
"CVE-2009-3814"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2009-10-27T16:30:00Z",
"severity": "MODERATE"
},
"details": "Static code injection vulnerability in RunCMS 2M1 allows remote authenticated administrators to execute arbitrary PHP code via the \"Filter/Banning\" feature, as demonstrated by modifying modules/system/cache/bademails.php using the \"Prohibited: Emails\" action, and other unspecified filters.",
"id": "GHSA-6jvj-64ff-4p62",
"modified": "2022-05-02T03:48:49Z",
"published": "2022-05-02T03:48:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2009-3814"
},
{
"type": "WEB",
"url": "http://retrogod.altervista.org/9sg_runcms_forum_sql.html"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-6M4C-55QP-F477
Vulnerability from github – Published: 2022-05-17 04:49 – Updated: 2022-05-17 04:49The x_button method in the ServiceController (vmdb/app/controllers/service_controller.rb) in Red Hat CloudForms 3.0 Management Engine 5.2 allows remote attackers to execute arbitrary methods via unspecified vectors.
{
"affected": [],
"aliases": [
"CVE-2014-0057"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2014-03-18T17:02:00Z",
"severity": "HIGH"
},
"details": "The x_button method in the ServiceController (vmdb/app/controllers/service_controller.rb) in Red Hat CloudForms 3.0 Management Engine 5.2 allows remote attackers to execute arbitrary methods via unspecified vectors.",
"id": "GHSA-6m4c-55qp-f477",
"modified": "2022-05-17T04:49:03Z",
"published": "2022-05-17T04:49:03Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2014-0057"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2014:0215"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2014-0057"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=1064140"
},
{
"type": "WEB",
"url": "http://rhn.redhat.com/errata/RHSA-2014-0215.html"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/57376"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-6M4W-J5FC-2M7R
Vulnerability from github – Published: 2022-05-02 04:01 – Updated: 2022-05-02 04:01Palm Pre WebOS 1.1 and earlier processes JavaScript in email messages, which allows remote attackers to execute arbitrary JavaScript, as demonstrated by reading PalmDatabase.db3.
{
"affected": [],
"aliases": [
"CVE-2009-5097"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2011-09-13T19:59:00Z",
"severity": "HIGH"
},
"details": "Palm Pre WebOS 1.1 and earlier processes JavaScript in email messages, which allows remote attackers to execute arbitrary JavaScript, as demonstrated by reading PalmDatabase.db3.",
"id": "GHSA-6m4w-j5fc-2m7r",
"modified": "2022-05-02T04:01:16Z",
"published": "2022-05-02T04:01:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2009-5097"
},
{
"type": "WEB",
"url": "http://kb.palm.com/wps/portal/kb/na/pre/p100eww/sprint/solutions/article/50607_en.html#12"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/36936"
},
{
"type": "WEB",
"url": "http://tlhsecurity.blogspot.com/2009/10/palm-pre-webos-11-remote-file-access.html"
},
{
"type": "WEB",
"url": "http://www.precentral.net/webos-1-2-fixed-serious-file-security-issue"
},
{
"type": "WEB",
"url": "http://www.securitytracker.com/id?1022987"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-6M5M-3PHV-F8FM
Vulnerability from github – Published: 2025-03-07 21:31 – Updated: 2025-03-10 18:31An issue in Docmosis Tornado v.2.9.7 and before allows a remote attacker to execute arbitrary code via a crafted script to the UNC path input
{
"affected": [],
"aliases": [
"CVE-2024-42733"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-07T21:15:17Z",
"severity": "CRITICAL"
},
"details": "An issue in Docmosis Tornado v.2.9.7 and before allows a remote attacker to execute arbitrary code via a crafted script to the UNC path input",
"id": "GHSA-6m5m-3phv-f8fm",
"modified": "2025-03-10T18:31:55Z",
"published": "2025-03-07T21:31:10Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42733"
},
{
"type": "WEB",
"url": "https://github.com/Docmosis/tornado-docker/issues/14"
},
{
"type": "WEB",
"url": "https://github.com/Marsman1996/pocs/blob/master/redox/CVE-2024-57492/README.md"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-6M8W-JC87-6CR7
Vulnerability from github – Published: 2025-05-01 17:02 – Updated: 2025-05-05 22:02Impact
When run as a server, OPA exposes an HTTP Data API for reading and writing documents. Requesting a virtual document through the Data API entails policy evaluation, where a Rego query containing a single data document reference is constructed from the requested path. This query is then used for policy evaluation.
A HTTP request path can be crafted in a way that injects Rego code into the constructed query. The evaluation result cannot be made to return any other data than what is generated by the requested path, but this path can be misdirected, and the injected Rego code can be crafted to make the query succeed or fail; opening up for oracle attacks or, given the right circumstances, erroneous policy decision results. Furthermore, the injected code can be crafted to be computationally expensive, resulting in a Denial Of Service (DoS) attack.
Users are only impacted if all of the following apply:
- OPA is deployed as a standalone server (rather than being used as a Go library)
- The OPA server is exposed outside of the local host in an untrusted environment.
- The configured authorization policy does not do exact matching of the
input.pathattribute when deciding if the request should be allowed.
or, if all of the following apply:
- OPA is deployed as a standalone server.
- The service connecting to OPA allows 3rd parties to insert unsanitised text into the path of the HTTP request to OPA’s Data API.
Note: With no Authorization Policy configured for restricting API access (the default configuration), the RESTful Data API provides access for managing Rego policies; and the RESTful Query API facilitates advanced queries. Full access to these APIs provides both simpler, and broader access than what the security issue describes here can facilitate. As such, OPA servers exposed to a network are not considered affected by the attack described here if they are knowingly not restricting access through an Authorization Policy.
Patches
Fixed in OPA v1.4.0.
Workarounds
Don’t publicly expose OPA’s RESTful APIs
Unless necessary for production reasons, network access to OPA’s RESTful APIs should be limited to localhost and/or trusted networks.
Since OPA v1.0, unless otherwise configured, the server listener defaults to localhost.
Enable Authentication to Only Allow Access to Trusted Clients
A configured authentication scheme is a requirement when OPA is exposed in an untrusted environment. While requiring authentication alone doesn’t mitigate this attack, it effectively reduces the scope from untrusted clients to trusted clients.
Perform Path Validation Using OPA’s Authorization Policy Functionality
OPA can be configured to use an Authorization Policy to validate all incoming requests. By authoring the Authorization Policy to only accept paths corresponding to expected Rego package references, this attack can be fully mitigated.
The HTTP path in a Data API request is of the format /v1/data/{path:.+} (/v0/data/{path:.+}, for the v0 Data API), where data/{path:.+} directly corresponds to a reference to a virtual document, and a prefix of {path:.+} corresponds to a Rego package declaration.
E.g. the HTTP path v1/data/do/re/mi corresponds to the data reference data.do.re.mi, where do.re is the package and mi is the rule in the following Rego module:
package do.re
mi if {
...
}
Unless otherwise configured, OPA will use the rule at data.system.authz.allow as Authorization Policy. Authorization is enabled by starting OPA with the --authorization=basic flag, and the Authorization policy must be made available to the OPA runtime either through a bundle (via the --bundle flag or through discovery) or as an individual module via the command-line.
A trivial Authorization Policy example:
package system.authz
allowed_paths := [
["v1", "data", "policy1", "allow"],
["v1", "data", "policy2", "allow"],
...
]
allow if {
input.path in allowed_paths
}
Note: configuring an Authorization Policy in OPA isn't the only way to protect against malicious request paths. Path validation and sanitisation can also be performed by connecting clients and 3rd party intermediaries, such as API gateways, reverse proxies, etc.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/open-policy-agent/opa/v1/server"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.4.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/open-policy-agent/opa/server"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.4.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/open-policy-agent/opa"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.4.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-46569"
],
"database_specific": {
"cwe_ids": [
"CWE-770",
"CWE-78",
"CWE-94"
],
"github_reviewed": true,
"github_reviewed_at": "2025-05-01T17:02:58Z",
"nvd_published_at": "2025-05-01T20:15:37Z",
"severity": "HIGH"
},
"details": "### Impact\n\nWhen run as a server, OPA exposes an HTTP[ Data API](https://www.openpolicyagent.org/docs/latest/rest-api/#data-api) for reading and writing documents. Requesting a virtual document through the Data API entails policy evaluation, where a Rego query containing a single data document [reference](https://www.openpolicyagent.org/docs/latest/policy-language/#references) is constructed from the requested path. This query is then used for policy evaluation.\n\nA HTTP request path can be crafted in a way that injects Rego code into the constructed query. The evaluation result cannot be made to return any other data than what is generated by the requested path, but this path can be misdirected, and the injected Rego code can be crafted to make the query succeed or fail; opening up for oracle attacks or, given the right circumstances, erroneous policy decision results. Furthermore, the injected code can be crafted to be computationally expensive, resulting in a Denial Of Service (DoS) attack.\n\n**Users are only impacted if all of the following apply:**\n\n* OPA is deployed as a standalone server (rather than being used as a Go library)\n* The OPA server is exposed outside of the local host in an untrusted environment.\n* The configured [authorization policy](https://www.openpolicyagent.org/docs/latest/security/#authentication-and-authorization) does not do exact matching of the `input.path` attribute when deciding if the request should be allowed.\n\n**or, if all of the following apply:**\n\n* OPA is deployed as a standalone server.\n* The service connecting to OPA allows 3rd parties to insert unsanitised text into the path of the HTTP request to OPA\u2019s Data API.\n\n**Note:** With **no** Authorization Policy configured for restricting API access (the default configuration), the RESTful Data API provides access for managing Rego policies; and the RESTful Query API facilitates advanced queries. Full access to these APIs provides both simpler, and broader access than what the security issue describes here can facilitate. As such, OPA servers exposed to a network are **not** considered affected by the attack described here if they are knowingly not restricting access through an Authorization Policy.\n\n### Patches\n\nFixed in OPA v1.4.0.\n\n### Workarounds\n\n#### Don\u2019t publicly expose OPA\u2019s RESTful APIs ####\n\nUnless necessary for production reasons, network access to OPA\u2019s RESTful APIs should be limited to `localhost` and/or trusted networks. \nSince OPA v1.0, unless otherwise configured, the server listener defaults to `localhost`.\n\n#### Enable Authentication to Only Allow Access to Trusted Clients ####\n\nA configured [authentication](https://www.openpolicyagent.org/docs/latest/security/#authentication-and-authorization) scheme is a requirement when OPA is exposed in an untrusted environment. While requiring authentication alone doesn\u2019t mitigate this attack, it effectively reduces the scope from untrusted clients to trusted clients.\n\n#### Perform Path Validation Using OPA\u2019s Authorization Policy Functionality ####\n\nOPA can be configured to use an [Authorization Policy](https://www.openpolicyagent.org/docs/latest/security/#authentication-and-authorization) to validate all incoming requests.\nBy authoring the Authorization Policy to only accept paths corresponding to expected Rego package references, this attack can be fully mitigated.\n\nThe HTTP path in a Data API request is of the format `/v1/data/{path:.+}` (`/v0/data/{path:.+}`, for the v0 Data API), where `data/{path:.+}` directly corresponds to a reference to a virtual document, and a prefix of `{path:.+}` corresponds to a Rego `package` declaration. \nE.g. the HTTP path `v1/data/do/re/mi` corresponds to the data reference `data.do.re.mi`, where `do.re` is the package and `mi` is the rule in the following Rego module:\n\n```rego\npackage do.re\n\nmi if {\n\t...\n}\n```\n\nUnless otherwise [configured](https://www.openpolicyagent.org/docs/latest/configuration/#miscellaneous), OPA will use the rule at `data.system.authz.allow` as Authorization Policy. Authorization is enabled by starting OPA with the `--authorization=basic` flag, and the Authorization policy must be made available to the OPA runtime either through a bundle (via the `--bundle` flag or through [discovery](https://www.openpolicyagent.org/docs/latest/management-discovery/)) or as an individual module via the command-line.\n\nA trivial Authorization Policy example:\n\n```rego\npackage system.authz\n\nallowed_paths := [\n\t[\"v1\", \"data\", \"policy1\", \"allow\"],\n\t[\"v1\", \"data\", \"policy2\", \"allow\"],\n\t...\n]\n\nallow if {\n\tinput.path in allowed_paths\n}\n```\n\n**Note:** configuring an Authorization Policy in OPA isn\u0027t the only way to protect against malicious request paths. Path validation and sanitisation can also be performed by connecting clients and 3rd party intermediaries, such as API gateways, reverse proxies, etc.",
"id": "GHSA-6m8w-jc87-6cr7",
"modified": "2025-05-05T22:02:31Z",
"published": "2025-05-01T17:02:58Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/open-policy-agent/opa/security/advisories/GHSA-6m8w-jc87-6cr7"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-46569"
},
{
"type": "WEB",
"url": "https://github.com/open-policy-agent/opa/commit/ad2063247a14711882f18c387a511fc8094aa79c"
},
{
"type": "PACKAGE",
"url": "https://github.com/open-policy-agent/opa"
},
{
"type": "WEB",
"url": "https://pkg.go.dev/vuln/GO-2025-3660"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:N/VA:H/SC:H/SI:H/SA:H",
"type": "CVSS_V4"
}
],
"summary": "OPA server Data API HTTP path injection of Rego"
}
GHSA-6M9P-64VV-XH22
Vulnerability from github – Published: 2022-05-14 02:11 – Updated: 2022-05-14 02:11epan/dissectors/packet-nfs.c in the NFS dissector in Wireshark 1.4.x before 1.4.14, 1.6.x before 1.6.9, and 1.8.x before 1.8.1 allows remote attackers to cause a denial of service (loop and CPU consumption) via a crafted packet.
{
"affected": [],
"aliases": [
"CVE-2012-4049"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2012-07-24T19:55:00Z",
"severity": "LOW"
},
"details": "epan/dissectors/packet-nfs.c in the NFS dissector in Wireshark 1.4.x before 1.4.14, 1.6.x before 1.6.9, and 1.8.x before 1.8.1 allows remote attackers to cause a denial of service (loop and CPU consumption) via a crafted packet.",
"id": "GHSA-6m9p-64vv-xh22",
"modified": "2022-05-14T02:11:23Z",
"published": "2022-05-14T02:11:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2012-4049"
},
{
"type": "WEB",
"url": "https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7436"
},
{
"type": "WEB",
"url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A15707"
},
{
"type": "WEB",
"url": "http://anonsvn.wireshark.org/viewvc/trunk/epan/dissectors/packet-nfs.c?r1=43576\u0026r2=43575\u0026pathrev=43576"
},
{
"type": "WEB",
"url": "http://anonsvn.wireshark.org/viewvc?view=revision\u0026revision=43576"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-updates/2012-08/msg00000.html"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/49971"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/54425"
},
{
"type": "WEB",
"url": "http://www.gentoo.org/security/en/glsa/glsa-201308-05.xml"
},
{
"type": "WEB",
"url": "http://www.wireshark.org/security/wnpa-sec-2012-12.html"
}
],
"schema_version": "1.4.0",
"severity": []
}
Mitigation
Strategy: Refactoring
Refactor your program so that you do not have to dynamically generate code.
Mitigation
- Run your code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which code can be executed by your product.
- Examples include the Unix chroot jail and AppArmor. In general, managed code may provide some protection.
- This may not be a feasible solution, and it only limits the impact to the operating system; the rest of your application may still be subject to compromise.
- Be careful to avoid CWE-243 and other weaknesses related to jails.
Mitigation MIT-5
Strategy: Input Validation
- Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
- When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
- Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
- To reduce the likelihood of code injection, use stringent allowlists that limit which constructs are allowed. If you are dynamically constructing code that invokes a function, then verifying that the input is alphanumeric might be insufficient. An attacker might still be able to reference a dangerous function that you did not intend to allow, such as system(), exec(), or exit().
Mitigation
Use dynamic tools and techniques that interact with the product using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, and fault injection. The product's operation may slow down, but it should not become unstable, crash, or generate incorrect results.
Mitigation MIT-32
Strategy: Compilation or Build Hardening
Run the code in an environment that performs automatic taint propagation and prevents any command execution that uses tainted variables, such as Perl's "-T" switch. This will force the program to perform validation steps that remove the taint, although you must be careful to correctly validate your inputs so that you do not accidentally mark dangerous inputs as untainted (see CWE-183 and CWE-184).
Mitigation MIT-32
Strategy: Environment Hardening
Run the code in an environment that performs automatic taint propagation and prevents any command execution that uses tainted variables, such as Perl's "-T" switch. This will force the program to perform validation steps that remove the taint, although you must be careful to correctly validate your inputs so that you do not accidentally mark dangerous inputs as untainted (see CWE-183 and CWE-184).
Mitigation
For Python programs, it is frequently encouraged to use the ast.literal_eval() function instead of eval, since it is intentionally designed to avoid executing code. However, an adversary could still cause excessive memory or stack consumption via deeply nested structures [REF-1372], so the python documentation discourages use of ast.literal_eval() on untrusted data [REF-1373].
CAPEC-242: Code Injection
An adversary exploits a weakness in input validation on the target to inject new code into that which is currently executing. This differs from code inclusion in that code inclusion involves the addition or replacement of a reference to a code file, which is subsequently loaded by the target and used as part of the code of some application.
CAPEC-35: Leverage Executable Code in Non-Executable Files
An attack of this type exploits a system's trust in configuration and resource files. When the executable loads the resource (such as an image file or configuration file) the attacker has modified the file to either execute malicious code directly or manipulate the target process (e.g. application server) to execute based on the malicious configuration parameters. Since systems are increasingly interrelated mashing up resources from local and remote sources the possibility of this attack occurring is high.
CAPEC-77: Manipulating User-Controlled Variables
This attack targets user controlled variables (DEBUG=1, PHP Globals, and So Forth). An adversary can override variables leveraging user-supplied, untrusted query variables directly used on the application server without any data sanitization. In extreme cases, the adversary can change variables controlling the business logic of the application. For instance, in languages like PHP, a number of poorly set default configurations may allow the user to override variables.