diff --git a/tools/apitester/__snapshots__/cassette_TestCommand_JavareachArchive.snap b/tools/apitester/__snapshots__/cassette_TestCommand_JavareachArchive.snap index 14a3130fa68..41ed5f3873e 100755 --- a/tools/apitester/__snapshots__/cassette_TestCommand_JavareachArchive.snap +++ b/tools/apitester/__snapshots__/cassette_TestCommand_JavareachArchive.snap @@ -247,6 +247,10 @@ {}, { "vulns": [ + { + "id": "GHSA-355h-qmc2-wpwf", + "modified": "" + }, { "id": "GHSA-cj7v-27pg-wf7q", "modified": "" @@ -544,6 +548,10 @@ {}, { "vulns": [ + { + "id": "GHSA-355h-qmc2-wpwf", + "modified": "" + }, { "id": "GHSA-cj7v-27pg-wf7q", "modified": "" diff --git a/tools/apitester/__snapshots__/cassette_single_query.snap b/tools/apitester/__snapshots__/cassette_single_query.snap index b9138890767..9386689a2e9 100755 --- a/tools/apitester/__snapshots__/cassette_single_query.snap +++ b/tools/apitester/__snapshots__/cassette_single_query.snap @@ -258,7 +258,7 @@ "id": "CVE-2026-22693", "summary": "Null Pointer Dereference in SubtableUnicodesCache::create leading to DoS", "details": "HarfBuzz is a text shaping engine. Prior to version 12.3.0, a null pointer dereference vulnerability exists in the SubtableUnicodesCache::create function located in src/hb-ot-cmap-table.hh. The function fails to check if hb_malloc returns NULL before using placement new to construct an object at the returned pointer address. When hb_malloc fails to allocate memory (which can occur in low-memory conditions or when using custom allocators that simulate allocation failures), it returns NULL. The code then attempts to call the constructor on this null pointer using placement new syntax, resulting in undefined behavior and a Segmentation Fault. This issue has been patched in version 12.3.0.", - "aliases": ["GHSA-xvjr-f2r9-c7ww"], + "aliases": ["ECHO-7ecb-7a01-33a3", "GHSA-xvjr-f2r9-c7ww"], "modified": "", "published": "2026-01-10T05:53:21.019Z", "related": [ @@ -901,8 +901,8 @@ "id": "CURL-CVE-2025-10966", "summary": "missing SFTP host verification with wolfSSH", "details": "curl's code for managing SSH connections when SFTP was done using the wolfSSH\npowered backend was flawed and missed host verification mechanisms.\n\nThis prevents curl from detecting MITM attackers and more.", - "aliases": ["CVE-2025-10966"], - "modified": "", + "aliases": ["CVE-2025-10966", "ECHO-84eb-3f66-73a1"], + "modified": "", "published": "2025-11-05T08:00:00Z", "database_specific": "", "affected": [ @@ -952,7 +952,7 @@ "id": "CURL-CVE-2025-14017", "summary": "broken TLS options for threaded LDAPS", "details": "When doing multi-threaded LDAPS transfers (LDAP over TLS) with libcurl,\nchanging TLS options in one thread would inadvertently change them globally\nand therefore possibly also affect other concurrently setup transfers.\n\nDisabling certificate verification for a specific transfer could\nunintentionally disable the feature for other threads as well.", - "aliases": ["CVE-2025-14017"], + "aliases": ["CVE-2025-14017", "ECHO-8091-7fb3-2ea0"], "modified": "", "published": "2026-01-07T08:00:00Z", "database_specific": "", @@ -1003,7 +1003,7 @@ "id": "CURL-CVE-2025-14524", "summary": "bearer token leak on cross-protocol redirect", "details": "When an OAuth2 bearer token is used for an HTTP(S) transfer, and that transfer\nperforms a cross-protocol redirect to a second URL that uses an IMAP, LDAP,\nPOP3 or SMTP scheme, curl might wrongly pass on the bearer token to the new\ntarget host.", - "aliases": ["CVE-2025-14524"], + "aliases": ["CVE-2025-14524", "ECHO-5c48-9921-1026"], "modified": "", "published": "2026-01-06T08:00:00Z", "database_specific": "", @@ -1105,7 +1105,7 @@ "id": "CURL-CVE-2025-15079", "summary": "libssh global known_hosts override", "details": "When doing SSH-based transfers using either SCP or SFTP, and setting the\nknown_hosts file, libcurl could still mistakenly accept connecting to hosts\n*not present* in the specified file if they were added as recognized in the\nlibssh *global* known_hosts file.", - "aliases": ["CVE-2025-15079"], + "aliases": ["CVE-2025-15079", "ECHO-77ba-e0af-7bbd"], "modified": "", "published": "2026-01-07T08:00:00Z", "database_specific": "", @@ -1156,7 +1156,7 @@ "id": "CURL-CVE-2025-15224", "summary": "libssh key passphrase bypass without agent set", "details": "When doing SSH-based transfers using either SCP or SFTP, and asked to do\npublic key authentication, curl would wrongly still ask and authenticate using\na locally running SSH agent.", - "aliases": ["CVE-2025-15224"], + "aliases": ["CVE-2025-15224", "ECHO-a8e4-f399-f8ec"], "modified": "", "published": "2026-01-07T08:00:00Z", "database_specific": "", @@ -1258,7 +1258,7 @@ "id": "CURL-CVE-2026-1965", "summary": "bad reuse of HTTP Negotiate connection", "details": "libcurl can in some circumstances reuse the wrong connection when asked to do\nan Negotiate-authenticated HTTP or HTTPS request.\n\nlibcurl features a pool of recent connections so that subsequent requests can\nreuse an existing connection to avoid overhead.\n\nWhen reusing a connection a range of criterion must first be met. Due to a\nlogical error in the code, a request that was issued by an application could\nwrongfully reuse an existing connection to the same server that was\nauthenticated using different credentials. One underlying reason being that\nNegotiate sometimes authenticates *connections* and not *requests*, contrary\nto how HTTP is designed to work.\n\nAn application that allows Negotiate authentication to a server (that responds\nwanting Negotiate) with `user1:password1` and then does another operation to\nthe same server also using Negotiate but with `user2:password2` (while the\nprevious connection is still alive) - the second request wrongly reused the\nsame connection and since it then sees that the Negotiate negotiation is\nalready made, it just sends the request over that connection thinking it uses\nthe user2 credentials when it is in fact still using the connection\nauthenticated for user1...\n\nThe set of authentication methods to use is set with `CURLOPT_HTTPAUTH`.\n\nApplications can disable libcurl's reuse of connections and thus mitigate this\nproblem, by using one of the following libcurl options to alter how\nconnections are or are not reused: `CURLOPT_FRESH_CONNECT`,\n`CURLOPT_MAXCONNECTS` and `CURLMOPT_MAX_HOST_CONNECTIONS` (if using the\ncurl_multi API).", - "aliases": ["CVE-2026-1965"], + "aliases": ["CVE-2026-1965", "ECHO-3c02-5957-bbd3"], "modified": "", "published": "2026-03-11T08:00:00Z", "database_specific": "", @@ -1309,7 +1309,7 @@ "id": "CURL-CVE-2026-3783", "summary": "token leak with redirect and netrc", "details": "When an OAuth2 bearer token is used for an HTTP(S) transfer, and that transfer\nperforms a redirect to a second URL, curl could leak that token to the second\nhostname under some circumstances.\n\nIf the hostname that the first request is redirected to has information in the\nused .netrc file, with either of the `machine` or `default` keywords, curl\nwould pass on the bearer token set for the first host also to the second one.", - "aliases": ["CVE-2026-3783"], + "aliases": ["CVE-2026-3783", "ECHO-de93-d97b-29a9"], "modified": "", "published": "2026-03-11T08:00:00Z", "database_specific": "", @@ -1360,7 +1360,7 @@ "id": "CURL-CVE-2026-3784", "summary": "wrong proxy connection reuse with credentials", "details": "curl would wrongly reuse an existing HTTP proxy connection doing CONNECT to a\nserver, even if the new request uses different credentials for the HTTP proxy.\nThe proper behavior is to create or use a separate connection.", - "aliases": ["CVE-2026-3784"], + "aliases": ["CVE-2026-3784", "ECHO-f726-ae66-88e1"], "modified": "", "published": "2026-03-11T08:00:00Z", "database_specific": "", @@ -2462,7 +2462,7 @@ { "id": "CVE-2025-10966", "details": "curl's code for managing SSH connections when SFTP was done using the wolfSSH\npowered backend was flawed and missed host verification mechanisms.\n\nThis prevents curl from detecting MITM attackers and more.", - "aliases": ["CURL-CVE-2025-10966"], + "aliases": ["CURL-CVE-2025-10966", "ECHO-84eb-3f66-73a1"], "modified": "", "published": "2025-11-07T08:15:39.617Z", "related": ["openSUSE-SU-2025:15757-1"], @@ -2516,7 +2516,7 @@ { "id": "CVE-2025-14017", "details": "When doing multi-threaded LDAPS transfers (LDAP over TLS) with libcurl,\nchanging TLS options in one thread would inadvertently change them globally\nand therefore possibly also affect other concurrently setup transfers.\n\nDisabling certificate verification for a specific transfer could\nunintentionally disable the feature for other threads as well.", - "aliases": ["CURL-CVE-2025-14017"], + "aliases": ["CURL-CVE-2025-14017", "ECHO-8091-7fb3-2ea0"], "modified": "", "published": "2026-01-08T10:15:45.667Z", "related": [ @@ -2579,7 +2579,7 @@ { "id": "CVE-2025-14524", "details": "When an OAuth2 bearer token is used for an HTTP(S) transfer, and that transfer\nperforms a cross-protocol redirect to a second URL that uses an IMAP, LDAP,\nPOP3 or SMTP scheme, curl might wrongly pass on the bearer token to the new\ntarget host.", - "aliases": ["CURL-CVE-2025-14524"], + "aliases": ["CURL-CVE-2025-14524", "ECHO-5c48-9921-1026"], "modified": "", "published": "2026-01-08T10:15:46.607Z", "related": [ @@ -2709,7 +2709,7 @@ { "id": "CVE-2025-15079", "details": "When doing SSH-based transfers using either SCP or SFTP, and setting the\nknown_hosts file, libcurl could still mistakenly accept connecting to hosts\n*not present* in the specified file if they were added as recognized in the\nlibssh *global* known_hosts file.", - "aliases": ["CURL-CVE-2025-15079"], + "aliases": ["CURL-CVE-2025-15079", "ECHO-77ba-e0af-7bbd"], "modified": "", "published": "2026-01-08T10:15:47.100Z", "related": [ @@ -2776,7 +2776,7 @@ { "id": "CVE-2025-15224", "details": "When doing SSH-based transfers using either SCP or SFTP, and asked to do\npublic key authentication, curl would wrongly still ask and authenticate using\na locally running SSH agent.", - "aliases": ["CURL-CVE-2025-15224"], + "aliases": ["CURL-CVE-2025-15224", "ECHO-a8e4-f399-f8ec"], "modified": "", "published": "2026-01-08T10:15:47.207Z", "related": [ @@ -2900,7 +2900,7 @@ { "id": "CVE-2026-1965", "details": "libcurl can in some circumstances reuse the wrong connection when asked to do\nan Negotiate-authenticated HTTP or HTTPS request.\n\nlibcurl features a pool of recent connections so that subsequent requests can\nreuse an existing connection to avoid overhead.\n\nWhen reusing a connection a range of criterion must first be met. Due to a\nlogical error in the code, a request that was issued by an application could\nwrongfully reuse an existing connection to the same server that was\nauthenticated using different credentials. One underlying reason being that\nNegotiate sometimes authenticates *connections* and not *requests*, contrary\nto how HTTP is designed to work.\n\nAn application that allows Negotiate authentication to a server (that responds\nwanting Negotiate) with `user1:password1` and then does another operation to\nthe same server also using Negotiate but with `user2:password2` (while the\nprevious connection is still alive) - the second request wrongly reused the\nsame connection and since it then sees that the Negotiate negotiation is\nalready made, it just sends the request over that connection thinking it uses\nthe user2 credentials when it is in fact still using the connection\nauthenticated for user1...\n\nThe set of authentication methods to use is set with `CURLOPT_HTTPAUTH`.\n\nApplications can disable libcurl's reuse of connections and thus mitigate this\nproblem, by using one of the following libcurl options to alter how\nconnections are or are not reused: `CURLOPT_FRESH_CONNECT`,\n`CURLOPT_MAXCONNECTS` and `CURLMOPT_MAX_HOST_CONNECTIONS` (if using the\ncurl_multi API).", - "aliases": ["CURL-CVE-2026-1965"], + "aliases": ["CURL-CVE-2026-1965", "ECHO-3c02-5957-bbd3"], "modified": "", "published": "2026-03-11T11:15:59.177Z", "related": [ @@ -2958,7 +2958,7 @@ { "id": "CVE-2026-3783", "details": "When an OAuth2 bearer token is used for an HTTP(S) transfer, and that transfer\nperforms a redirect to a second URL, curl could leak that token to the second\nhostname under some circumstances.\n\nIf the hostname that the first request is redirected to has information in the\nused .netrc file, with either of the `machine` or `default` keywords, curl\nwould pass on the bearer token set for the first host also to the second one.", - "aliases": ["CURL-CVE-2026-3783"], + "aliases": ["CURL-CVE-2026-3783", "ECHO-de93-d97b-29a9"], "modified": "", "published": "2026-03-11T11:16:00.080Z", "related": [ @@ -3024,7 +3024,7 @@ { "id": "CVE-2026-3784", "details": "curl would wrongly reuse an existing HTTP proxy connection doing CONNECT to a\nserver, even if the new request uses different credentials for the HTTP proxy.\nThe proper behavior is to create or use a separate connection.", - "aliases": ["CURL-CVE-2026-3784"], + "aliases": ["CURL-CVE-2026-3784", "ECHO-f726-ae66-88e1"], "modified": "", "published": "2026-03-11T11:16:00.437Z", "related": [ @@ -3403,7 +3403,7 @@ "id": "GHSA-cpwx-vrp4-4pq7", "summary": "Jinja2 vulnerable to sandbox breakout through attr filter selecting format method", "details": "An oversight in how the Jinja sandboxed environment interacts with the `|attr` filter allows an attacker that controls the content of a template to execute arbitrary Python code.\n\nTo exploit the vulnerability, an attacker needs to control the content of a template. Whether that is the case depends on the type of application using Jinja. This vulnerability impacts users of applications which execute untrusted templates.\n\nJinja's sandbox does catch calls to `str.format` and ensures they don't escape the sandbox. However, it's possible to use the `|attr` filter to get a reference to a string's plain format method, bypassing the sandbox. After the fix, the `|attr` filter no longer bypasses the environment's attribute lookup.", - "aliases": ["CVE-2025-27516"], + "aliases": ["CVE-2025-27516", "ECHO-d102-c54d-3424"], "modified": "", "published": "2025-03-05T20:40:14Z", "related": ["CGA-xx5r-cxh4-797p"], @@ -3620,7 +3620,7 @@ "id": "GHSA-cpwx-vrp4-4pq7", "summary": "Jinja2 vulnerable to sandbox breakout through attr filter selecting format method", "details": "An oversight in how the Jinja sandboxed environment interacts with the `|attr` filter allows an attacker that controls the content of a template to execute arbitrary Python code.\n\nTo exploit the vulnerability, an attacker needs to control the content of a template. Whether that is the case depends on the type of application using Jinja. This vulnerability impacts users of applications which execute untrusted templates.\n\nJinja's sandbox does catch calls to `str.format` and ensures they don't escape the sandbox. However, it's possible to use the `|attr` filter to get a reference to a string's plain format method, bypassing the sandbox. After the fix, the `|attr` filter no longer bypasses the environment's attribute lookup.", - "aliases": ["CVE-2025-27516"], + "aliases": ["CVE-2025-27516", "ECHO-d102-c54d-3424"], "modified": "", "published": "2025-03-05T20:40:14Z", "related": ["CGA-xx5r-cxh4-797p"], @@ -3837,7 +3837,7 @@ "id": "GHSA-cpwx-vrp4-4pq7", "summary": "Jinja2 vulnerable to sandbox breakout through attr filter selecting format method", "details": "An oversight in how the Jinja sandboxed environment interacts with the `|attr` filter allows an attacker that controls the content of a template to execute arbitrary Python code.\n\nTo exploit the vulnerability, an attacker needs to control the content of a template. Whether that is the case depends on the type of application using Jinja. This vulnerability impacts users of applications which execute untrusted templates.\n\nJinja's sandbox does catch calls to `str.format` and ensures they don't escape the sandbox. However, it's possible to use the `|attr` filter to get a reference to a string's plain format method, bypassing the sandbox. After the fix, the `|attr` filter no longer bypasses the environment's attribute lookup.", - "aliases": ["CVE-2025-27516"], + "aliases": ["CVE-2025-27516", "ECHO-d102-c54d-3424"], "modified": "", "published": "2025-03-05T20:40:14Z", "related": ["CGA-xx5r-cxh4-797p"],