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.
8381 vulnerabilities reference this CWE, most recent first.
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": []
}
GHSA-6MF5-36V9-3H2W
Vulnerability from github – Published: 2023-06-20 16:46 – Updated: 2023-06-20 16:46Impact
Any user with view rights on any document can execute code with programming rights, leading to remote code execution by crafting an url with a dangerous payload. See the example below:
Open <xwiki-host>/xwiki/bin/view/%5D%5D%20%7B%7Basync%20async%3D%22true%22%20cached%3D%22false%22%20context%3D%22doc.reference%22%7D%7D%7B%7Bgroovy%7D%7Dprintln(%22Hello%20%22%20%2B%20%22from%20groovy!%22)%7B%7B%2Fgroovy%7D%7D%7B%7B%2Fasync%7D%7D?sheet=Invitation.InvitationGuestActions&xpage=view where <xwiki-host> is the URL of your XWiki installation.
Patches
The problem as been patching on XWiki 15.0, 14.10.4 and 14.4.8.
Workarounds
It is possible to partially fix the issue by applying this patch. Note that some additional issue can remain and can be fixed automatically by a migration. Hence, it is advised to upgrade to one of the patched version instead of patching manually.
References
- https://jira.xwiki.org/browse/XWIKI-20285
For more information
If you have any questions or comments about this advisory:
- Open an issue in Jira XWiki.org
- Email us at Security Mailing List
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.xwiki.platform:xwiki-platform-invitation-ui"
},
"ranges": [
{
"events": [
{
"introduced": "2.4-m-2"
},
{
"fixed": "14.4.8"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.xwiki.platform:xwiki-platform-invitation-ui"
},
"ranges": [
{
"events": [
{
"introduced": "14.5"
},
{
"fixed": "14.10.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.xwiki.platform:xwiki-platform-invitation-ui"
},
"ranges": [
{
"events": [
{
"introduced": "15.0-rc-1"
},
{
"fixed": "15.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-35150"
],
"database_specific": {
"cwe_ids": [
"CWE-94",
"CWE-95"
],
"github_reviewed": true,
"github_reviewed_at": "2023-06-20T16:46:11Z",
"nvd_published_at": "2023-06-23T17:15:09Z",
"severity": "CRITICAL"
},
"details": "### Impact\nAny user with view rights on any document can execute code with programming rights, leading to remote code execution by crafting an url with a dangerous payload. See the example below:\nOpen `\u003cxwiki-host\u003e/xwiki/bin/view/%5D%5D%20%7B%7Basync%20async%3D%22true%22%20cached%3D%22false%22%20context%3D%22doc.reference%22%7D%7D%7B%7Bgroovy%7D%7Dprintln(%22Hello%20%22%20%2B%20%22from%20groovy!%22)%7B%7B%2Fgroovy%7D%7D%7B%7B%2Fasync%7D%7D?sheet=Invitation.InvitationGuestActions\u0026xpage=view` where `\u003cxwiki-host\u003e` is the URL of your XWiki installation.\n\n### Patches\nThe problem as been patching on XWiki 15.0, 14.10.4 and 14.4.8.\n\n### Workarounds\nIt is possible to partially fix the issue by applying this [patch](https://github.com/xwiki/xwiki-platform/commit/b65220a4d86b8888791c3b643074ebca5c089a3a). Note that some additional issue can remain and can be fixed automatically by a migration. Hence, it is advised to upgrade to one of the patched version instead of patching manually.\n\n### References\n- https://jira.xwiki.org/browse/XWIKI-20285\n\n### For more information\n\nIf you have any questions or comments about this advisory:\n\n* Open an issue in [Jira XWiki.org](https://jira.xwiki.org/)\n* Email us at [Security Mailing List](mailto:security@xwiki.org)",
"id": "GHSA-6mf5-36v9-3h2w",
"modified": "2023-06-20T16:46:11Z",
"published": "2023-06-20T16:46:11Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/xwiki/xwiki-platform/security/advisories/GHSA-6mf5-36v9-3h2w"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-35150"
},
{
"type": "WEB",
"url": "https://github.com/xwiki/xwiki-platform/commit/b65220a4d86b8888791c3b643074ebca5c089a3a"
},
{
"type": "PACKAGE",
"url": "https://github.com/xwiki/xwiki-platform"
},
{
"type": "WEB",
"url": "https://jira.xwiki.org/browse/XWIKI-20285"
}
],
"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:L",
"type": "CVSS_V3"
}
],
"summary": "XWiki Platform vulnerable to privilege escalation (PR) from view right via Invitation application"
}
GHSA-6MGP-V5CM-GHG5
Vulnerability from github – Published: 2024-05-15 20:27 – Updated: 2024-05-15 20:27In Drupal core, when sending email some variables were not being sanitized for shell arguments in DefaultMailSystem::mail(), which could lead to remote code execution.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "drupal/core"
},
"ranges": [
{
"events": [
{
"introduced": "7.0"
},
{
"fixed": "7.60"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "drupal/core"
},
"ranges": [
{
"events": [
{
"introduced": "8.0.0"
},
{
"fixed": "8.5.8"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "drupal/core"
},
"ranges": [
{
"events": [
{
"introduced": "8.6.0"
},
{
"fixed": "8.6.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": true,
"github_reviewed_at": "2024-05-15T20:27:23Z",
"nvd_published_at": null,
"severity": "CRITICAL"
},
"details": "In Drupal core, when sending email some variables were not being sanitized for shell arguments in `DefaultMailSystem::mail()`, which could lead to remote code execution.",
"id": "GHSA-6mgp-v5cm-ghg5",
"modified": "2024-05-15T20:27:23Z",
"published": "2024-05-15T20:27:23Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/drupal/core/2018-10-17-4.yaml"
},
{
"type": "PACKAGE",
"url": "https://github.com/drupal/core"
},
{
"type": "WEB",
"url": "https://www.drupal.org/sa-core-2018-006"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "Drupal core Remote Code Execution"
}
GHSA-6MJ7-M8R8-G28V
Vulnerability from github – Published: 2024-03-31 03:30 – Updated: 2024-03-31 03:30A command injection vulnerability in Ivanti Sentry prior to 9.19.0 allows unauthenticated threat actor to execute arbitrary commands on the underlying operating system of the appliance within the same physical or logical network.
{
"affected": [],
"aliases": [
"CVE-2023-41724"
],
"database_specific": {
"cwe_ids": [
"CWE-77",
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-31T02:15:07Z",
"severity": "CRITICAL"
},
"details": "A command injection vulnerability in Ivanti Sentry prior to 9.19.0 allows unauthenticated threat actor to execute arbitrary commands on the underlying operating system of the appliance within the same physical or logical network. ",
"id": "GHSA-6mj7-m8r8-g28v",
"modified": "2024-03-31T03:30:27Z",
"published": "2024-03-31T03:30:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-41724"
},
{
"type": "WEB",
"url": "https://forums.ivanti.com/s/article/CVE-2023-41724-Remote-Code-Execution-for-Ivanti-Standalone-Sentry"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:A/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-6MPG-FQXP-QCP9
Vulnerability from github – Published: 2022-05-17 01:57 – Updated: 2022-05-17 01:57IBM InfoSphere Information Server 9.1, 11.3, and 11.5 could allow a local user to gain elevated privileges by placing arbitrary files in installation directories. IBM X-Force ID: 128468.
{
"affected": [],
"aliases": [
"CVE-2017-1469"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-08-14T22:29:00Z",
"severity": "HIGH"
},
"details": "IBM InfoSphere Information Server 9.1, 11.3, and 11.5 could allow a local user to gain elevated privileges by placing arbitrary files in installation directories. IBM X-Force ID: 128468.",
"id": "GHSA-6mpg-fqxp-qcp9",
"modified": "2022-05-17T01:57:32Z",
"published": "2022-05-17T01:57:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-1469"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/128468"
},
{
"type": "WEB",
"url": "http://www.ibm.com/support/docview.wss?uid=swg22006069"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/100309"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
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.