Summary
XAResource.recover() in MariaDB Connector/J trusted the gtridlength and bquallength columns returned by XA RECOVER to allocate and split each Xid.
Details
MariaDbPoolConnection and MariaDbPoolPinnedConnection built each Xid of the recovery list by allocating new byte[gtridlength] and new byte[bquallength] and copying from the data column, without validating the lengths against the XA specification bounds (Xid.MAXGTRIDSIZE, Xid.MAXBQUALSIZE) or the actual payload. Negative or oversized lengths, or lengths that do not fit the data, ended in large allocations or unchecked exceptions (NegativeArraySizeException, ArrayIndexOutOfBoundsException) during recovery.
The fix validates the lengths before any allocation or copy and reports an invalid row as an XAException (XAERRMFAIL).
Impact
Availability only, and limited to applications running XA recovery: a malicious or compromised server, or a MitM, can crash the recovery or drive large allocations. Exploitation requires control of the server side of the connection.
Credit
Reported by fg0x0
Summary
BigInteger.prototype.modInverse() in node-forge's bundled jsbn library enters an infinite loop when the value or the modulus is negative, for example when a negative public exponent is passed to forge.pki.rsa.generateKeyPair(). This is an incomplete fix of CVE-2026-33891 (GHSA-5m6q-g25r-mvwx), which handled only a zero value. Fixed in node-forge 1.4.1.
Details
bnModInverse() (lib/jsbn.js, exposed as forge.jsbn.BigInteger.prototype.modInverse) implements the binary extended Euclidean algorithm (Handbook of Applied Cryptography, Algorithm 14.61), which is defined for positive integers. With a negative operand the loop cannot terminate: rShiftTo is an arithmetic shift, so a negative value never moves towards zero, and the loop's exit condition (u reaching zero) is never met. The calling thread spins at 100% CPU indefinitely; in Node.js this blocks the event loop. Memory does not grow.
node-forge 1.4.0 fixed CVE-2026-33891 (GHSA-5m6q-g25r-mvwx) by returning zero early when this.signum() == 0, although its changelog describes the check as "<= 0". Negative values were not covered, and a negative modulus was never handled. Every negative input that did terminate already returned zero.
Within node-forge, RSA key generation is the only path to a negative operand: the caller's public exponent e becomes BigInteger.fromInt(e), and state.e.modInverse(state.phi) is called with it. gcd() works on absolute values, so the coprimality checks pass and the loop is reached. Any exponent other than 3 or 65537 uses the pure JavaScript implementation, even when forge.options.usePureJavaScript is not set. RFC 8017, Section 3.1 requires the RSA public exponent to be at least 3.
Values that node-forge parses (DER, PEM, JWK, PKCS#12, X.509, TLS) are always read as unsigned integers and cannot produce a negative operand.
The fix makes modInverse() return zero when the value or the modulus is zero or negative, as it already does when no inverse exists. Results for positive inputs are unchanged.
This issue was reported by wzc.
Patches Fixed in node-forge 1.4.1. modInverse() now returns zero when the value or the modulus is zero or negative.
Workarounds - Pass only fixed, valid RSA public exponents (e.g. 65537) to key generation, or validate caller-supplied exponents first: an odd integer >= 3. - Do not call BigInteger#modInverse() with negative operands. Reduce the value modulo a positive modulus first (x.mod(m).modInverse(m)).
Proof of concept
A negative public exponent passed to RSA key generation never returns (also with the callback form and with createKeyPairGenerationState() / stepKeyPairGenerationState()):
var forge = require('node-forge'); forge.pki.rsa.generateKeyPair({bits: 256, e: -1}); // hangs at 100% CPU
Calling modInverse() directly with a negative value or modulus hangs the same way:
var BigInteger = forge.jsbn.BigInteger; new BigInteger('-1').modInverse(new BigInteger('7')); // hangs new BigInteger('3').modInverse(new BigInteger('-7')); // hangs
With the fix, these calls return zero. The regression tests are in tests/unit/jsbn.js.
Impact
Applications are affected only if they: - pass an untrusted value as the RSA public exponent e to forge.pki.rsa.generateKeyPair(), forge.pki.rsa.createKeyPairGenerationState() or forge.pki.rsa.stepKeyPairGenerationState(), or - call forge.jsbn.BigInteger#modInverse() directly with negative values derived from untrusted input.
An attacker who can supply such a value makes the call hang indefinitely at 100% CPU, which blocks the Node.js event loop (denial of service). Keys and other data parsed by node-forge (DER, PEM, JWK, PKCS#12, X.509, TLS) cannot trigger this issue, and the documented usage of key generation passes a constant exponent (65537). There is no effect on confidentiality or integrity.
Summary
When a CA store created by pki.createCaStore() holds two or more certificates with the same subject name, pki.verifyCertificateChain() permanently removes those certificates from the store while trying each one as the issuer. A peer can send any certificate that names that subject as its issuer to make all later verifications against those CA certificates fail. Fixed in node-forge 1.4.1.
Details
pki.verifyCertificateChain() (lib/x509.js) asks the CA store for the issuer of each certificate with caStore.getIssuer(). When the store holds several certificates with the same subject, caStore.getIssuer() returns the store's own internal array of those certificates (caStore.certs[hash], built by addCertificate()). verifyCertificateChain() used that array directly as its list of candidate parents and called parents.shift() on it while trying each candidate. Every candidate it tried, including the one that finally verified the certificate, was removed from the store.
Once the array is empty, getIssuer() returns an empty list, no candidate is tried, and verification fails with "Certificate signature is invalid." hasCertificate() and listAllCertificates() no longer see the removed certificates. The store stays in this state for as long as the object is used.
The attacker's certificate only needs an issuer name equal to the shared subject name, which is public. Its signature and key can be arbitrary: every candidate is tried and shifted out because none verifies, and errors from parent.verify() are caught by the loop. Verification of the attacker's chain fails as expected. Verifying valid chains has a similar effect: the CA certificate that verified the chain and any tried before it are removed.
No chain is accepted that should be rejected. Removing candidates can only turn a success into a failure.
RFC 5280, Section 6.1.1(d) treats trust anchor information as an input to path validation. Validation should not consume it.
The fix copies the array returned by getIssuer() before iterating over it, so the CA store is no longer modified. getIssuer() itself is unchanged.
Patches Fixed in node-forge 1.4.1. pki.verifyCertificateChain() now works on a copy of the candidate issuer list instead of shifting entries out of the CA store.
Workarounds - Pass a fresh CA store to each pki.verifyCertificateChain() call (for example pki.createCaStore(trustedCerts)), or pass caStore to forge.tls.createConnection() as an array of certificates instead of a store object, so that forge creates a new store per connection. - Or wrap the store so that getIssuer() returns a copy:
var getIssuer = caStore.getIssuer; caStore.getIssuer = function(cert) { var r = getIssuer(cert); return Array.isArray(r) ? r.slice() : r; };
Proof of concept
Two trusted self-signed CA certificates, rootA and rootB, share the subject CN=Root. bogus is any certificate whose issuer is CN=Root, signed with an unrelated key. leafA is a valid certificate issued by rootA.
var caStore = forge.pki.createCaStore([rootA, rootB]); caStore.listAllCertificates().length; // 2 try { forge.pki.verifyCertificateChain(caStore, [bogus]); } catch(e) {} // rejected as expected ("Certificate signature is invalid.") caStore.listAllCertificates().length; // 0: both CA certificates are gone forge.pki.verifyCertificateChain(caStore, [leafA]); // throws "Certificate signature is invalid." (valid chain now rejected)
Without the attacker certificate, verifying leafA twice against a fresh store gives the same result: the first call succeeds and removes rootA, the second fails. With the fix, the store keeps both certificates and every valid chain verifies. The regression tests are in tests/unit/x509.js ("CA store" section).
Impact
Applications that keep a long-lived CA store holding several trusted certificates with the same subject name, and that verify certificate chains received from other parties with pki.verifyCertificateChain(). This includes forge.tls clients that pass the same caStore object to several connections. Duplicate subject names occur with re-keyed or renewed CAs that kept their name, or a CA next to a cross-signed version of itself, mostly in private PKIs.
A remote, unauthenticated peer (for example a malicious TLS server or a party submitting a signed document) can send a certificate naming the shared subject as its issuer. This removes every certificate with that subject from the store, so later verifications of valid chains issued by those CA certificates fail until the store is recreated. This is a persistent denial of service for certificate verification against those CA certificates. Verification against other trusted CAs keeps working, no invalid chain is accepted, and stores without duplicate subject names are not affected.
Forge (also called node-forge) is a native implementation of Transport Layer Security in JavaScript. Prior to 1.4.1, the affected implementation used decipher.finish(), CBC and ECB modes, PKCS#7 padding to process the relevant input or security decision. node-forge validated only the final byte of PKCS#7 padding during CBC and ECB decryption and accepted zero, oversized, or mismatched padding bytes. Malformed ciphertext could consequently be accepted and up to four plaintext blocks could be silently removed, causing an integrity failure in applications that treated successful decryption as proof of valid padding. This issue is fixed in version 1.4.1.
Summary
asn1.oidToDer() did not range-check the first two arcs of an OID string, so an OID such as 0.42.840.113549.1.1.1 or 4294977127.18.840.113549.1.1.1 was encoded as the DER of a different OID (here rsaEncryption, 1.2.840.113549.1.1.1). This is an incomplete fix of CVE-2025-66030. Fixed in node-forge 1.4.1.
Details
X.690 section 8.19 encodes the first two arcs of an OID as one subidentifier, 40 arc1 + arc2, where the first arc is 0, 1 or 2 and the second arc is at most 39 when the first is 0 or 1. asn1.oidToDer() in lib/asn1.js computed that value with no range check and wrote it with putByte(), which keeps only the low 16 bits. Out-of-range first arcs therefore produced the encoding of a different OID: 0.42.840.113549.1.1.1 gives 40 0 + 42 = 42 and 4294977127.18.840.113549.1.1.1 wraps to 42, both the first byte of rsaEncryption. The fix for CVE-2025-66030 (GHSA-65ch-62r8-g69g, node-forge 1.3.2) added a 32-bit check for the later arcs only.
A related encoding bug made valid OIDs with a first subidentifier above 127 (2.48 and higher, e.g. 2.999) encode and decode incorrectly, because the first subidentifier was always written and read as a single byte.
The fix rejects out-of-range first arcs and encodes and decodes the first subidentifier in base 128 like the others (the latter from public PR #1148).
Patches Fixed in node-forge 1.4.1. asn1.oidToDer() throws for OIDs with out-of-range first arcs, and the first subidentifier is encoded and decoded correctly.
Workarounds Validate OID strings from untrusted input before passing them to node-forge: the first arc must be 0, 1 or 2, and the second arc at most 39 when the first arc is 0 or 1.
Credits Reported by wzc. The first subidentifier encoding fix is from PR #1148 by @spokodev.
Proof of concept
var forge = require('node-forge'); var der = forge.asn1.oidToDer('0.42.840.113549.1.1.1'); console.log(der.toHex()); // 2a864886f70d010101 console.log(forge.asn1.derToOid(der)); // 1.2.840.113549.1.1.1
On 1.4.0 the out-of-range OID string encodes to exactly the DER of rsaEncryption (the same happens with 4294977127.18.840.113549.1.1.1). On 1.4.1 oidToDer() throws "Invalid OID; the first two arcs are out of range.".
Regression tests are in tests/unit/asn1.js ("should reject OIDs with out of range first arcs").
Impact
Applications that accept OID strings from untrusted input, check or authorize them as strings, and then encode them with node-forge (for example when building certificates, CSRs or other ASN.1 structures from user-supplied extension or attribute OIDs) can be made to emit a different, trusted OID than the one that was checked. Parsing DER is not affected. There is no confidentiality or availability impact.
Forge (also called node-forge) is a native implementation of Transport Layer Security in JavaScript. Prior to 1.4.1, the affected implementation used certificate.verify(child), verifySignature(), lib/x509.js to process the relevant input or security decision. node-forge selected RSA padding and RSASSA-PSS parameters from the issuer certificate rather than the child certificate being verified. A child labeled as RSASSA-PSS could therefore be accepted with a PKCS#1 v1.5 signature when the issuer used PKCS#1 v1.5. The signature still had to be produced with the trusted issuer's private key, so this did not permit certificate identity forgery, but it could bypass policies that require a declared signature scheme. This issue is fixed in version 1.4.1.
Cedar users must be using all of the following features to be affected by this advisory: JSON format policies, policy templates, and the is in scope condition. This advisory only affects JSON-formatted Cedar policy templates containing is in scope conditions that are malformed according to the Cedar syntax. It does not affect syntactically well-formed policies.
Users of Cedar who author policies in the JSON format were able to write Cedar policies using the is in condition with an incorrect slot identifier in the principal and resource scope constraints (e.g., ?principal in the resource scope constraint) even though this is not allowed when parsing policies from the Cedar policy syntax. Internally, the slot identifiers were silently corrected (e.g. ?resource is placed in the resource scope constraint).
If the policy contains exactly one slot in either the principal or resource position, then any attempt to create a linked policy from the template results in an error: the internal representation of the template does not contain the slot identifier as written in the malformed JSON policy (it has been corrected silently), so attempting to fill that slot is an error. If instead the template is linked using slot identifier expected internally (i.e., not what is written in the JSON template), the linking will initially succeed, but a subsequent invariant violation will cause a panic.
When the template contains slots in both the principal and resource position, then both slots will be present in the internal representation: linking succeeds, but with each slot bound to the value intended for the other (the silent correction). The linked policy is then semantically different from the malformed policy the user intended, and any subsequent authorization decision made against that policy may lead to accesses being unintentionally allowed or denied.
Concretely, consider the following JSON format policy template intended to deny users in a particular project from accessing documents with a particular classification. { "effect": "forbid", "principal": { "op": "is", "entitytype": "User", "in": { "slot": "?resource" } }, "action": { "op": "All" }, "resource": { "op": "is", "entitytype": "Doc", "in": { "slot": "?principal" } }, "conditions": [] }
Linked with ?principal = Classification::"topsecret" and ?resource = Project::"alpha", the author expects to create the policy: forbid(principal is User in Project::"alpha", action, resource is Doc in Classification::"topsecret");
But because Cedar internally links slots by scope position (not by name), the actual policy evaluated by the engine is: forbid(principal is User in Classification::"topsecret", action, resource is Doc in Project::"alpha");
If a user is in Project::"alpha" but not Classification::"topsecret", the forbid policy does not apply, and access is unintentionally allowed.
Patches
This advisory is patched in version 4.11.1 and 3.4.3, both available on Crates.io and NPM.
Workarounds
If you cannot update to a patched version, you can determine if you are affected by checking your JSON format policy templates for the following two patterns.
"principal": { "op": "is", "entitytype": "User", "in": { "slot": "?resource" } }
and "resource": { "op": "is", "entitytype": "Doc", "in": { "slot": "?principal" } }
References Cedar Policy Language Reference Guide - Cedar Policy Templates Cedar Policy Language Reference Guide - JSON Policy Format
Impact
Parse Server's file upload validation uses the fileUpload.fileExtensions option (enabled by default with a blocklist) to reject files that browsers may render as active content, mitigating stored cross-site scripting (XSS). When an uploaded file's extension is not recognized by the mime package, Parse Server preserves the client-supplied Content-Type and passes it to the storage adapter. A malformed Content-Type that is not a valid type/subtype media type — for example image (no subtype), image/ (empty subtype), or image//svg+xml (invalid token) — bypassed the blocklist and was stored unchanged. On storage adapters that persist and serve the uploaded Content-Type (such as Amazon S3, Google Cloud Storage, or Azure Blob Storage), a browser cannot parse the malformed Content-Type and falls back to MIME-sniffing the file content; a file whose body begins with HTML markup is then rendered as HTML, executing any embedded script in the application's origin. This allows a user permitted to upload files to store content that executes as script against other users who open the file URL. The default GridFS storage adapter is not affected, as it recomputes the Content-Type from the filename and serves files with X-Content-Type-Options: nosniff.
Patches
The file upload handler now validates that the client-supplied Content-Type is a well-formed media type (type/subtype with non-empty tokens per RFC 9110 §5.6.2) whenever the filename extension is not recognized by mime. Malformed values are rejected instead of being stored, while well-formed types — including custom or vendor types that the mime package does not recognize — continue to be accepted; only blocklisted subtypes are rejected.
Workarounds
Configure fileUpload.fileExtensions as a strict allowlist of only the extensions the application needs (for example ["^(png|jpe?g|gif|pdf)$"]). Additionally, serve uploaded files from a domain separate from the application so that any rendered content is isolated from the application's origin, and configure the storage/CDN layer to send X-Content-Type-Options: nosniff.
References
- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-r899-h629-j84r - Fix Parse Server 9: https://github.com/parse-community/parse-server/pull/10521 - Fix Parse Server 8: https://github.com/parse-community/parse-server/pull/10523
Impact
Parse Server's file upload validation uses the fileUpload.fileExtensions option (enabled by default with a blocklist) to reject files that browsers may render as active content, mitigating stored cross-site scripting (XSS). When an uploaded file's extension is not recognized by the mime package, Parse Server preserves the client-supplied Content-Type and passes it to the storage adapter. A malformed Content-Type that is not a valid type/subtype media type — for example image (no subtype), image/ (empty subtype), or image//svg+xml (invalid token) — bypassed the blocklist and was stored unchanged. On storage adapters that persist and serve the uploaded Content-Type (such as Amazon S3, Google Cloud Storage, or Azure Blob Storage), a browser cannot parse the malformed Content-Type and falls back to MIME-sniffing the file content; a file whose body begins with HTML markup is then rendered as HTML, executing any embedded script in the application's origin. This allows a user permitted to upload files to store content that executes as script against other users who open the file URL. The default GridFS storage adapter is not affected, as it recomputes the Content-Type from the filename and serves files with X-Content-Type-Options: nosniff.
Patches
The file upload handler now validates that the client-supplied Content-Type is a well-formed media type (type/subtype with non-empty tokens per RFC 9110 §5.6.2) whenever the filename extension is not recognized by mime. Malformed values are rejected instead of being stored, while well-formed types — including custom or vendor types that the mime package does not recognize — continue to be accepted; only blocklisted subtypes are rejected.
Workarounds
Configure fileUpload.fileExtensions as a strict allowlist of only the extensions the application needs (for example ["^(png|jpe?g|gif|pdf)$"]). Additionally, serve uploaded files from a domain separate from the application so that any rendered content is isolated from the application's origin, and configure the storage/CDN layer to send X-Content-Type-Options: nosniff.
References
- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-r899-h629-j84r - Fix Parse Server 9: https://github.com/parse-community/parse-server/pull/10521 - Fix Parse Server 8: https://github.com/parse-community/parse-server/pull/10523
Summary During the resource pack stage of logging in, after the server sends ResourcePackStackPacket, a malicious client can send a batch of multiple ResourcePackClientResponsePacket packets with status ResourcePackClientResponsePacket::STATUSCOMPLETED causing the server to repeatedly execute pre-spawn progression.
Impact Multiple Player objects can be created for just a single session, increasing memory usage and amplifying outbound network traffic from duplication of large pre-spawn packets such as AvailableCommandsPacket and CreativeContentPacket.
Workarounds Plugins can use their own PacketHandler classes that reject/ignore any extra ResourcePackClientResponsePacket packets.
Patches This issue was patched in https://github.com/pmmp/PocketMine-MP/commit/7a27894146a04964ab628ed9033140fdbf887ff3 and released in 5.44.2.
Wasmtime before 36.0.18, 37.0.0 before 48.0.6, and 49.0.0 before 49.0.3 does not verify that set-path-with-query values in wasmtime-wasi-http are paths, so absolute-form URLs are written verbatim as the HTTP/1.1 request target while the connection uses the allowed authority. A malicious guest can supply an absolute URL that a forward proxy or gateway at that authority honors, reaching hosts disallowed by embedder filtering policies.
Parse Server before 8.6.106 and 9.0.0 before 9.10.5-alpha.7 mishandles dot notation keys with null or undefined values when building the saved object, so a write is stored but returns an error and skips afterSave triggers and LiveQuery events. A client with write access can exploit this to evade audit logging, notifications, and derived data updates.
Parse Server before 8.6.107 and 9.0.0 before 9.10.5-alpha.8 returns the stored value of a field reverted by a beforeSave trigger in object update responses, even to clients without read access to that object or field. An authenticated client able to update an object whose beforeSave trigger reverts a field, via revert() or a constant: true validator, can read protected values, including its own account's raw MFA authData when protectedFieldsTriggerExempt is enabled.
P-Net before 1.0.3 passes the application alarm callback a data length derived from the variable part length field of a received RTA alarm frame without checking it against the length of the received frame. A short frame can make the callback receive a length of up to 65507 bytes. An application that copies the reported number of bytes reads past the end of the receive buffer. The attacker must have established an Application Relationship and requires ADJACENT network access. Applications that do not use the alarm data are not affected.
Initialization of a resource with an insecure default vulnerability in OpenText Advanced Authentication Server allows Excessive Allocation.
This issue affects Advanced Authentication Server: from 6.4.0.0 through 6.4.3.x, from 6.5.0.0 through 6.5.0.x, and from 6.6.0.0 through 6.6.1.0.
The fix for this is issue is to create a secure configuration. The 6.6.2.0 release has a best practice entry if the configuration is unsecure.
A secure configuration is to NOT allow creation/recreation of Unauthenticated Endpoints. If creation/recreation of Unauthenticated Endpoints is required, you should only allow it from trusted networks.
To remedy this issue, change your configuration to NOT allow creation/recreation of Unauthenticated Endpoints. If you require Unauthenticated Endpoints, you MUST change your configuration to use a non-empty whitelist to specify the trusted networks. An empty whitelist will allow all networks to create/recreate endpoints.
Szafir is vulnerable to Path Traversal in the uploaded filename. A man-in-the-middle attacker who can reroute update request to their server can prepare arbitrary XML file that will be saved in location chosen by attacker.
This issue was fixed in version 2.0 build 708.
JeeSite 5.11.0 through 5.19.1 contains an insecure direct object reference vulnerability in the AI CMS chat module that allows authenticated users to access other users' conversations due to missing and reversed ownership checks. Attackers who know or derive a victim's conversation id can call /a/cms/chat/message, /a/cms/chat/delete, or /a/cms/chat/completions to read, delete, or append to the victim's AI chat transcripts.
A flaw was found in polkit. When processing input that begins with a null byte, an arithmetic error in the authentication agent helper causes an integer underflow during buffer length calculation, resulting in an out-of-bounds memory read. An attacker capable of supplying crafted input can trigger this flaw, potentially causing an application crash and resulting in a Denial of Service (DoS).
Mutt is a small but very powerful text-based mail client for Unix operating systems. Security Fix(es):
heap OOB write in convertfilefromto() via a crafted Content-Type header allows attacker to OOB write when email is used as a template.(CVE-2026-107570)
Mutt is a small but very powerful text-based mail client for Unix operating systems. Security Fix(es):
heap OOB write in convertfilefromto() via a crafted Content-Type header allows attacker to OOB write when email is used as a template.(CVE-2026-107570)
Mutt is a small but very powerful text-based mail client for Unix operating systems. Security Fix(es):
heap OOB write in convertfilefromto() via a crafted Content-Type header allows attacker to OOB write when email is used as a template.(CVE-2026-107570)
Mutt is a small but very powerful text-based mail client for Unix operating systems. Security Fix(es):
heap OOB write in convertfilefromto() via a crafted Content-Type header allows attacker to OOB write when email is used as a template.(CVE-2026-107570)
OpenSSL is a robust, commercial-grade, and full-featured toolkit for the Transport Layer Security (TLS) and Secure Sockets Layer (SSL) protocols. Security Fix(es):
Issue summary: A non-constant-time optimized implementation of scalar point multiplication is used for SM2 private key operations on ARM64 and RISC-V platforms.
Impact summary: An attacker able to measure the time taken by, or to observe the cache-line access pattern of SM2 signing or decryption on an affected platform can learn information about the secret scalar.
CWE: CWE-208: Observable Timing Discrepancy
Description: On ARM64 and RISC-V processors, the SM2 curve uses an optimized scalar multiplication implementation whose conditional branches and table look ups are chosen according to the bits of the secret scalar. The execution time and the cache-access pattern therefore depend on the long-term private key (during SM2 decryption) or the per-signature nonce (during SM2 signature generation), forming a timing and cache side-channel.
FIPS Impact: no SM2 is not a FIPS algorithm and the optimized SM2 implementation is not part of the FIPS module.
OpenSSL 4.0, 3.6, 3.5 and 3.4 are vulnerable to this issue on AArch64 and RISC-V.
OpenSSL 3.0, 1.1.1 and 1.0.2 are not affected by this issue.
OpenSSL 4.0 users should upgrade to OpenSSL 4.0.3. OpenSSL 3.6 users should upgrade to OpenSSL 3.6.5. OpenSSL 3.5 users should upgrade to OpenSSL 3.5.9. OpenSSL 3.4 users should upgrade to OpenSSL 3.4.8.
This issue was reported on 2 May 2026 by Abhinav Agarwal. It was independently reported on 6 June 2026 by Feng Xue. The fix was developed by Igor Ustinov.
-- cut (non-publishing metadata for internal use) -- Reported by: Abhinav Agarwal, Feng Xue Fixed by: Igor Ustinov(CVE-2026-54875)
OpenSSL is a robust, commercial-grade, and full-featured toolkit for the Transport Layer Security (TLS) and Secure Sockets Layer (SSL) protocols. Security Fix(es):
Issue summary: A non-constant-time optimized implementation of scalar point multiplication is used for SM2 private key operations on ARM64 and RISC-V platforms.
Impact summary: An attacker able to measure the time taken by, or to observe the cache-line access pattern of SM2 signing or decryption on an affected platform can learn information about the secret scalar.
CWE: CWE-208: Observable Timing Discrepancy
Description: On ARM64 and RISC-V processors, the SM2 curve uses an optimized scalar multiplication implementation whose conditional branches and table look ups are chosen according to the bits of the secret scalar. The execution time and the cache-access pattern therefore depend on the long-term private key (during SM2 decryption) or the per-signature nonce (during SM2 signature generation), forming a timing and cache side-channel.
FIPS Impact: no SM2 is not a FIPS algorithm and the optimized SM2 implementation is not part of the FIPS module.
OpenSSL 4.0, 3.6, 3.5 and 3.4 are vulnerable to this issue on AArch64 and RISC-V.
OpenSSL 3.0, 1.1.1 and 1.0.2 are not affected by this issue.
OpenSSL 4.0 users should upgrade to OpenSSL 4.0.3. OpenSSL 3.6 users should upgrade to OpenSSL 3.6.5. OpenSSL 3.5 users should upgrade to OpenSSL 3.5.9. OpenSSL 3.4 users should upgrade to OpenSSL 3.4.8.
This issue was reported on 2 May 2026 by Abhinav Agarwal. It was independently reported on 6 June 2026 by Feng Xue. The fix was developed by Igor Ustinov.
-- cut (non-publishing metadata for internal use) -- Reported by: Abhinav Agarwal, Feng Xue Fixed by: Igor Ustinov(CVE-2026-54875)
is an open-source BSD-licensed C programming library that provides streaming access to a variety of different archive formats, including tar, cpio, pax, zip, and ISO9660 images. The distribution also includes bsdtar and bsdcpio, full-featured implementations of tar and cpio that use . Security Fix(es):
A flaw was found in libarchive. An attacker can cause a Denial of Service (DoS) or potential information disclosure due to a use-after-free vulnerability, which occurs when a program reads memory that has already been released. This issue arises when the archiveentrycopymacmetadata() function deallocates an internal buffer before completing a data copy. An attacker who can supply input to an application utilizing this function can trigger the flaw to crash the application or read uninitialized memory data.(CVE-2026-17591)
is an open-source BSD-licensed C programming library that provides streaming access to a variety of different archive formats, including tar, cpio, pax, zip, and ISO9660 images. The distribution also includes bsdtar and bsdcpio, full-featured implementations of tar and cpio that use . Security Fix(es):
A flaw was found in libarchive. An attacker can cause a Denial of Service (DoS) or potential information disclosure due to a use-after-free vulnerability, which occurs when a program reads memory that has already been released. This issue arises when the archiveentrycopymacmetadata() function deallocates an internal buffer before completing a data copy. An attacker who can supply input to an application utilizing this function can trigger the flaw to crash the application or read uninitialized memory data.(CVE-2026-17591)
is an open-source BSD-licensed C programming library that provides streaming access to a variety of different archive formats, including tar, cpio, pax, zip, and ISO9660 images. The distribution also includes bsdtar and bsdcpio, full-featured implementations of tar and cpio that use . Security Fix(es):
A flaw was found in libarchive. An attacker can cause a Denial of Service (DoS) or potential information disclosure due to a use-after-free vulnerability, which occurs when a program reads memory that has already been released. This issue arises when the archiveentrycopymacmetadata() function deallocates an internal buffer before completing a data copy. An attacker who can supply input to an application utilizing this function can trigger the flaw to crash the application or read uninitialized memory data.(CVE-2026-17591)
A flaw in Node.js Permission Model filesystem enforcement leaves fs.realpathSync() without the required read permission checks. This is an incomplete fix of CVE-2026-21715, which only covered fs.realpathSync.native().
As a result, code running under --permission with restricted --allow-fs-read can still use fs.realpathSync() to check file existence, resolve symlink targets, and enumerate filesystem paths outside of permitted directories.
This vulnerability affects Node.js 26.x, 24.x, and 22.x.
A flaw in Node.js Permission Model filesystem enforcement leaves fs.realpathSync() without the required read permission checks. This is an incomplete fix of CVE-2026-21715, which only covered fs.realpathSync.native().
As a result, code running under --permission with restricted --allow-fs-read can still use fs.realpathSync() to check file existence, resolve symlink targets, and enumerate filesystem paths outside of permitted directories.
This vulnerability affects Node.js 26.x, 24.x, and 22.x.
A flaw in Node.js Permission Model filesystem enforcement can grant access to paths that do not match a wildcard --allow-fs-read or --allow-fs-write rule.
When the requested path is shorter than the prefix of a wildcard grant, the radix tree lookup stops comparing early and treats the path as a match. For example, --allow-fs-read=/etc/passwd. also allows reading /etc/passwd. This requires the wildcard grant to sit directly under the root of the permission tree, for example when it is the only grant for that scope. This is a different root cause from CVE-2026-58043.
This vulnerability affects Node.js 26.x.