🚨 CVE-2026-41728
Spring Data REST's JSON Patch (application/json-patch+json) implementation does not apply the write-access filter to intermediate path segments when resolving a multi-segment JSON Pointer.
Affected versions:
Spring Data REST 3.7.0 through 3.7.19; 4.3.0 through 4.3.16; 4.4.0 through 4.4.14; 4.5.0 through 4.5.11; 5.0.0 through 5.0.5.
🎖@cveNotify
Spring Data REST's JSON Patch (application/json-patch+json) implementation does not apply the write-access filter to intermediate path segments when resolving a multi-segment JSON Pointer.
Affected versions:
Spring Data REST 3.7.0 through 3.7.19; 4.3.0 through 4.3.16; 4.4.0 through 4.4.14; 4.5.0 through 4.5.11; 5.0.0 through 5.0.5.
🎖@cveNotify
Spring Data REST JSON Patch bypasses Jackson read-only property protection on nested objects and collections
Level up your Java code and explore what Spring can do for you.
🚨 CVE-2026-41729
Spring Data REST is vulnerable to SpEL expression injection through map-typed properties when processing JSON Patch (application/json-patch+json) requests. When a persistent entity exposes a Map-typed property, the JSON Pointer path segment used as the map key is embedded directly into a SpEL expression without sanitization or validation.
Affected versions:
Spring Data REST 3.7.0 through 3.7.19; 4.3.0 through 4.3.16; 4.4.0 through 4.4.14; 4.5.0 through 4.5.11; 5.0.0 through 5.0.5.
🎖@cveNotify
Spring Data REST is vulnerable to SpEL expression injection through map-typed properties when processing JSON Patch (application/json-patch+json) requests. When a persistent entity exposes a Map-typed property, the JSON Pointer path segment used as the map key is embedded directly into a SpEL expression without sanitization or validation.
Affected versions:
Spring Data REST 3.7.0 through 3.7.19; 4.3.0 through 4.3.16; 4.4.0 through 4.4.14; 4.5.0 through 4.5.11; 5.0.0 through 5.0.5.
🎖@cveNotify
Spring Data REST SpEL Injection via Map Key in JSON Patch
Level up your Java code and explore what Spring can do for you.
🚨 CVE-2026-41730
Spring Data REST serializes the full exception cause chain into HTTP error response bodies, potentially exposing persistence-layer internals to HTTP clients.
Affected versions:
Spring Data REST 3.7.0 through 3.7.19; 4.3.0 through 4.3.16; 4.4.0 through 4.4.14; 4.5.0 through 4.5.11; 5.0.0 through 5.0.5.
🎖@cveNotify
Spring Data REST serializes the full exception cause chain into HTTP error response bodies, potentially exposing persistence-layer internals to HTTP clients.
Affected versions:
Spring Data REST 3.7.0 through 3.7.19; 4.3.0 through 4.3.16; 4.4.0 through 4.4.14; 4.5.0 through 4.5.11; 5.0.0 through 5.0.5.
🎖@cveNotify
Spring Data REST exposes persistence-layer internals in error responses
Level up your Java code and explore what Spring can do for you.
🚨 CVE-2026-41731
JsonKafkaHeaderMapper and the deprecated DefaultKafkaHeaderMapper matched type headers against trusted packages using a prefix check, meaning that trusting any package implicitly trusted all of its subpackages. Combined with Jackson's default bean deserialization, a producer could supply crafted header values that caused the consumer to deserialize arbitrary JDK types.
Affected versions:
Spring for Apache Kafka 4.0.0 through 4.0.5; 3.3.0 through 3.3.15; 3.2.0 through 3.2.13; 2.9.0 through 2.9.13; 2.8.0 through 2.8.11.
🎖@cveNotify
JsonKafkaHeaderMapper and the deprecated DefaultKafkaHeaderMapper matched type headers against trusted packages using a prefix check, meaning that trusting any package implicitly trusted all of its subpackages. Combined with Jackson's default bean deserialization, a producer could supply crafted header values that caused the consumer to deserialize arbitrary JDK types.
Affected versions:
Spring for Apache Kafka 4.0.0 through 4.0.5; 3.3.0 through 3.3.15; 3.2.0 through 3.2.13; 2.9.0 through 2.9.13; 2.8.0 through 2.8.11.
🎖@cveNotify
In Spring for Apache Kafka, overly broad trusted-package matching in header mappers exposes JDK classes to deserialization
Level up your Java code and explore what Spring can do for you.
🚨 CVE-2026-41732
JsonPulsarHeaderMapper matched type headers against trusted packages using a prefix check, meaning that trusting any package implicitly trusted all of its subpackages. Additionally, an empty trusted-packages configuration fell back to trusting all packages rather than applying a safe default allow-list.
Affected versions:
Spring for Apache Pulsar 2.0.0 through 2.0.5; 1.2.0 through 1.2.17; 1.1.0 through 1.1.17.
🎖@cveNotify
JsonPulsarHeaderMapper matched type headers against trusted packages using a prefix check, meaning that trusting any package implicitly trusted all of its subpackages. Additionally, an empty trusted-packages configuration fell back to trusting all packages rather than applying a safe default allow-list.
Affected versions:
Spring for Apache Pulsar 2.0.0 through 2.0.5; 1.2.0 through 1.2.17; 1.1.0 through 1.1.17.
🎖@cveNotify
In Spring for Apache Pulsar, overly broad trusted-package matching in header mapper exposes JDK classes to deserialization
Level up your Java code and explore what Spring can do for you.
🚨 CVE-2026-41837
Spring Data REST's Querydsl integration accepts arbitrary persistent property paths as request-parameter filter keys and does not consider Jackson customizations before handing them to Querydsl.
Affected versions:
Spring Data REST 3.7.0 through 3.7.19; 4.3.0 through 4.3.16; 4.4.0 through 4.4.14; 4.5.0 through 4.5.11; 5.0.0 through 5.0.5.
🎖@cveNotify
Spring Data REST's Querydsl integration accepts arbitrary persistent property paths as request-parameter filter keys and does not consider Jackson customizations before handing them to Querydsl.
Affected versions:
Spring Data REST 3.7.0 through 3.7.19; 4.3.0 through 4.3.16; 4.4.0 through 4.4.14; 4.5.0 through 4.5.11; 5.0.0 through 5.0.5.
🎖@cveNotify
Spring Data REST Querydsl integration exposes Jackson-hidden persistent fields as filter keys
Level up your Java code and explore what Spring can do for you.
🚨 CVE-2026-44505
Nimiq is a Rust implementation of the Nimiq Proof-of-Stake protocol based on the Albatross consensus algorithm. network-libp2p handles kad get-record query progress in handle_dht_get (network-libp2p/src/swarm.rs). Prior to version 1.4.0, when a peer returns a FoundRecord, the code verifies the record via dht_verifier.verify(&record.record). On verifier error, handle_dht_get logs and returns early without completing the oneshot used by Network::dht_get, and without cleaning up per-query bookkeeping. Later query progress can hit the "DHT inconsistent state" path and also return without cleanup. Because Network::dht_get awaits the oneshot without a timeout, the caller future can hang indefinitely. This issue has been patched in version 1.4.0.
🎖@cveNotify
Nimiq is a Rust implementation of the Nimiq Proof-of-Stake protocol based on the Albatross consensus algorithm. network-libp2p handles kad get-record query progress in handle_dht_get (network-libp2p/src/swarm.rs). Prior to version 1.4.0, when a peer returns a FoundRecord, the code verifies the record via dht_verifier.verify(&record.record). On verifier error, handle_dht_get logs and returns early without completing the oneshot used by Network::dht_get, and without cleaning up per-query bookkeeping. Later query progress can hit the "DHT inconsistent state" path and also return without cleanup. Because Network::dht_get awaits the oneshot without a timeout, the caller future can hang indefinitely. This issue has been patched in version 1.4.0.
🎖@cveNotify
GitHub
Fix DHT GetRecord query wedge on untrusted peer responses by jsdanielh · Pull Request #3716 · nimiq/core-rs-albatross
An untrusted peer could respond to a DHT GetRecord query in ways that left the query in an inconsistent state, preventing it from ever completing and wedging the requester.
This change:
Adds DhtGe...
This change:
Adds DhtGe...
🚨 CVE-2026-45782
Cloud Hypervisor is a Virtual Machine Monitor for Cloud workloads. From version 21.0 to before version 51.2, a guest can cause a use-after-free in the cloud-hypervisor process by submitting two virtio-block descriptor chains that reuse the same head_index while asynchronous block I/O is enabled (e.g. io_uring, aio). When the kernel completes the duplicate operation before the original, the completion path frees a bounce buffer that the kernel is still actively reading from or writing to, corrupting the freed memory. This issue has been patched in versions 51.2 and 52.0.
🎖@cveNotify
Cloud Hypervisor is a Virtual Machine Monitor for Cloud workloads. From version 21.0 to before version 51.2, a guest can cause a use-after-free in the cloud-hypervisor process by submitting two virtio-block descriptor chains that reuse the same head_index while asynchronous block I/O is enabled (e.g. io_uring, aio). When the kernel completes the duplicate operation before the original, the completion path frees a bounce buffer that the kernel is still actively reading from or writing to, corrupting the freed memory. This issue has been patched in versions 51.2 and 52.0.
🎖@cveNotify
GitHub
build: Release v52.0 · cloud-hypervisor/cloud-hypervisor@1314ac8
Signed-off-by: Bo Chen <bchen@crusoe.ai>
🚨 CVE-2026-46411
FlashMQ is a MQTT broker/server, designed for multi-CPU environments. Prior to version 1.26.2, authorized clients have the ability to exceed the permitted over-commit of their write buffer and triggering an internal safe-guard exception. This exception was in a path that was not catchable, and therefore causes a server abort. This issue has been patched in version 1.26.2.
🎖@cveNotify
FlashMQ is a MQTT broker/server, designed for multi-CPU environments. Prior to version 1.26.2, authorized clients have the ability to exceed the permitted over-commit of their write buffer and triggering an internal safe-guard exception. This exception was in a path that was not catchable, and therefore causes a server abort. This issue has been patched in version 1.26.2.
🎖@cveNotify
GitHub
Fix uncatchable exception (buffer full) in sending PUBACKs · halfgaar/FlashMQ@29e08f7
The following error was seen aborting a running server:
"Trying to exceed circular buffer beyond its 2 GB limit"
This could happen when a client publishes (many) QoS packets tha...
"Trying to exceed circular buffer beyond its 2 GB limit"
This could happen when a client publishes (many) QoS packets tha...
🚨 CVE-2026-46432
LMDeploy is a toolkit for compressing, deploying, and serving large language models. In versions 0.12.3 and prior, LMDeploy is vulnerable to arbitrary code execution through hardcoded "trust_remote_code=True" in multiple HuggingFace model-loading call sites. At time of publication, there are no publicly available patches.
🎖@cveNotify
LMDeploy is a toolkit for compressing, deploying, and serving large language models. In versions 0.12.3 and prior, LMDeploy is vulnerable to arbitrary code execution through hardcoded "trust_remote_code=True" in multiple HuggingFace model-loading call sites. At time of publication, there are no publicly available patches.
🎖@cveNotify
GitHub
Arbitrary code execution via hardcoded trust_remote_code=True in lmdeploy model initialization
## Summary
lmdeploy hardcodes `trust_remote_code=True` in multiple HuggingFace model-loading call sites.
The affected code paths are in:
```text
lmdeploy/archs.py
lmdeploy/utils.py
````...
lmdeploy hardcodes `trust_remote_code=True` in multiple HuggingFace model-loading call sites.
The affected code paths are in:
```text
lmdeploy/archs.py
lmdeploy/utils.py
````...
🚨 CVE-2026-46491
SimpleSAMLphp-casserver is a CAS 1.0 and 2.0 compliant CAS server in the form of a SimpleSAMLphp module. Prior to version 7.0.3, simplesamlphp-module-casserver builds file paths for the file-based CAS ticket store by directly concatenating the configured ticket directory with an attacker-controlled ticket identifier. Public CAS validation/proxy endpoints pass attacker-controlled ticket / pgt query parameters into this store. In deployments using FileSystemTicketStore, a remote attacker can use path traversal sequences such as ../target.serialized to make the CAS server read and unserialize files outside the ticket directory. In the CAS 1.0 validation flow, the same attacker-selected path is also passed to deleteTicket() immediately after getTicket() returns, which can delete the target file when it is readable by the PHP process, deletable under the PHP process filesystem permissions, and unserializes to a value compatible with the ?array return type. This issue has been patched in version 7.0.3.
🎖@cveNotify
SimpleSAMLphp-casserver is a CAS 1.0 and 2.0 compliant CAS server in the form of a SimpleSAMLphp module. Prior to version 7.0.3, simplesamlphp-module-casserver builds file paths for the file-based CAS ticket store by directly concatenating the configured ticket directory with an attacker-controlled ticket identifier. Public CAS validation/proxy endpoints pass attacker-controlled ticket / pgt query parameters into this store. In deployments using FileSystemTicketStore, a remote attacker can use path traversal sequences such as ../target.serialized to make the CAS server read and unserialize files outside the ticket directory. In the CAS 1.0 validation flow, the same attacker-selected path is also passed to deleteTicket() immediately after getTicket() returns, which can delete the target file when it is readable by the PHP process, deletable under the PHP process filesystem permissions, and unserializes to a value compatible with the ?array return type. This issue has been patched in version 7.0.3.
🎖@cveNotify
GitHub
Merge commit from fork · simplesamlphp/simplesamlphp-module-casserver@b84f3e4
* Validate format of the ticket-parameter
* Canonicalize ticket file path and prevent breaking out of ticket directory
* Use a hash instead of the ticketId as a filename
* Harden against unseria...
* Canonicalize ticket file path and prevent breaking out of ticket directory
* Use a hash instead of the ticketId as a filename
* Harden against unseria...
🚨 CVE-2026-46517
LMDeploy is a toolkit for compressing, deploying, and serving large language models. In versions 0.12.3 and prior, hardcoded "trust_remote_code=True" enables HF supply-chain RCE without user opt-in. At time of publication, there are no publicly available patches.
🎖@cveNotify
LMDeploy is a toolkit for compressing, deploying, and serving large language models. In versions 0.12.3 and prior, hardcoded "trust_remote_code=True" enables HF supply-chain RCE without user opt-in. At time of publication, there are no publicly available patches.
🎖@cveNotify
GitHub
Hardcoded trust_remote_code=True is an implicit unsafe remote-code load path with no user opt-out (CWE-1188 default-insecure)
> ## 📋 Reframing (2026-05-02): implicit unsafe remote-code path, not "supply-chain"
>
> The accurate description of this vulnerability is:
> **"`get_model_arch` and relat...
>
> The accurate description of this vulnerability is:
> **"`get_model_arch` and relat...
🚨 CVE-2026-46518
OpenEMR is a free and open source electronic health records and medical practice management application. Prior to version 8.0.0.1, a stored cross-site scripting vulnerability in the prescription CSS/HTML multi-print feature allows a patient portal user to execute arbitrary JavaScript in a clinician's browser session. Patient demographic fields (name, address) are rendered without output encoding in multiprintcss_header(), and portal patients can write attacker-controlled HTML directly into patient_data by calling the PUT api/patient/:num endpoint, which bypasses the intended audit review workflow. Because the XSS fires in the clinician's authenticated session on the main OpenEMR interface, the attacker can access CSRF tokens, session data, and perform actions as the clinician — crossing the patient-to-clinician trust boundary. This issue has been patched in version 8.0.0.1.
🎖@cveNotify
OpenEMR is a free and open source electronic health records and medical practice management application. Prior to version 8.0.0.1, a stored cross-site scripting vulnerability in the prescription CSS/HTML multi-print feature allows a patient portal user to execute arbitrary JavaScript in a clinician's browser session. Patient demographic fields (name, address) are rendered without output encoding in multiprintcss_header(), and portal patients can write attacker-controlled HTML directly into patient_data by calling the PUT api/patient/:num endpoint, which bypasses the intended audit review workflow. Because the XSS fires in the clinician's authenticated session on the main OpenEMR interface, the attacker can access CSRF tokens, session data, and perform actions as the clinician — crossing the patient-to-clinician trust boundary. This issue has been patched in version 8.0.0.1.
🎖@cveNotify
GitHub
vuln06: Stored XSS in prescription CSS/HTML print view via patient demographics
### Summary
A stored cross-site scripting vulnerability in the prescription CSS/HTML multi-print feature allows a patient portal user to execute arbitrary JavaScript in a clinician's browser...
A stored cross-site scripting vulnerability in the prescription CSS/HTML multi-print feature allows a patient portal user to execute arbitrary JavaScript in a clinician's browser...
🚨 CVE-2026-46540
Nimiq is a Rust implementation of the Nimiq Proof-of-Stake protocol based on the Albatross consensus algorithm. Prior to version 1.4.0, when LightBlockchain::rebranch() adopts a fork chain whose tip is a macro block (checkpoint or election), it only updates self.head but fails to update self.macro_head, self.election_head, self.current_validators, or store the election header in the chain_store. This is in direct contrast with the full Blockchain::rebranch() at blockchain/src/blockchain/push.rs:504-518, which correctly updates all macro/election state when the new head is a macro block. After a rebranch to a macro block, the stale macro_head causes subsequent macro blocks pushed via push() to be verified against the wrong predecessor via verify_macro_successor(&this.macro_head). If the rebranch target was an election block, the stale current_validators causes every subsequent block to fail verify_validators(), completely stalling the light client's chain progression. This issue has been patched in version 1.4.0.
🎖@cveNotify
Nimiq is a Rust implementation of the Nimiq Proof-of-Stake protocol based on the Albatross consensus algorithm. Prior to version 1.4.0, when LightBlockchain::rebranch() adopts a fork chain whose tip is a macro block (checkpoint or election), it only updates self.head but fails to update self.macro_head, self.election_head, self.current_validators, or store the election header in the chain_store. This is in direct contrast with the full Blockchain::rebranch() at blockchain/src/blockchain/push.rs:504-518, which correctly updates all macro/election state when the new head is a macro block. After a rebranch to a macro block, the stale macro_head causes subsequent macro blocks pushed via push() to be verified against the wrong predecessor via verify_macro_successor(&this.macro_head). If the rebranch target was an election block, the stale current_validators causes every subsequent block to fail verify_validators(), completely stalling the light client's chain progression. This issue has been patched in version 1.4.0.
🎖@cveNotify
GitHub
Fixes rebranch logic in light blockchain by jsdanielh · Pull Request #3706 · nimiq/core-rs-albatross
Fix rebranch logic in the light blockchain to handle edge cases correctly.
Pull request checklist
All tests pass. The project builds and runs.
I have resolved any merge conflicts.
I have resolv...
Pull request checklist
All tests pass. The project builds and runs.
I have resolved any merge conflicts.
I have resolv...
🚨 CVE-2026-46541
Nimiq is a Rust implementation of the Nimiq Proof-of-Stake protocol based on the Albatross consensus algorithm. Prior to version 1.4.0, iIn handle_dht_get(), the DhtResults accumulator is only initialized when the first DHT record passes verification. If the first record fails (from a malicious DHT node), DhtResults is never created, and all subsequent valid records are discarded with "DHT inconsistent state" errors. This issue has been patched in version 1.4.0.
🎖@cveNotify
Nimiq is a Rust implementation of the Nimiq Proof-of-Stake protocol based on the Albatross consensus algorithm. Prior to version 1.4.0, iIn handle_dht_get(), the DhtResults accumulator is only initialized when the first DHT record passes verification. If the first record fails (from a malicious DHT node), DhtResults is never created, and all subsequent valid records are discarded with "DHT inconsistent state" errors. This issue has been patched in version 1.4.0.
🎖@cveNotify
GitHub
Fix for DHT query poisoning by jsdanielh · Pull Request #3707 · nimiq/core-rs-albatross
Harden DHT query handling against poisoning attempts.
Pull request checklist
All tests pass. The project builds and runs.
I have resolved any merge conflicts.
I have resolved all clippy and rus...
Pull request checklist
All tests pass. The project builds and runs.
I have resolved any merge conflicts.
I have resolved all clippy and rus...
🚨 CVE-2026-46542
Nimiq is a Rust implementation of the Nimiq Proof-of-Stake protocol based on the Albatross consensus algorithm. Prior to version 1.4.0, a denial-of-service vulnerability exists in the Ed25519 multisig delinearization code path. Ed25519PublicKey::delinearize() in keys/src/multisig/mod.rs called .unwrap() on curve point decompression, which panics when a public key is constructed from 32 bytes that do not represent a valid point on the Ed25519 curve. Ed25519PublicKey construction only validates byte length, not curve membership, so invalid keys can reach the delinearization path and crash the hosting process. This issue has been patched in version 1.4.0.
🎖@cveNotify
Nimiq is a Rust implementation of the Nimiq Proof-of-Stake protocol based on the Albatross consensus algorithm. Prior to version 1.4.0, a denial-of-service vulnerability exists in the Ed25519 multisig delinearization code path. Ed25519PublicKey::delinearize() in keys/src/multisig/mod.rs called .unwrap() on curve point decompression, which panics when a public key is constructed from 32 bytes that do not represent a valid point on the Ed25519 curve. Ed25519PublicKey construction only validates byte length, not curve membership, so invalid keys can reach the delinearization path and crash the hosting process. This issue has been patched in version 1.4.0.
🎖@cveNotify
GitHub
Multisig: return errors instead of panicking on invalid curve points when delinearizing by jsdanielh · Pull Request #3713 · nimiq/core…
What's in this pull request?
Ed25519PublicKey::delinearize() called .unwrap() on curve point decompression, which panics when given 32-byte public keys that aren't valid Ed25519 poi...
Ed25519PublicKey::delinearize() called .unwrap() on curve point decompression, which panics when given 32-byte public keys that aren't valid Ed25519 poi...
🚨 CVE-2026-46543
Nimiq is a Rust implementation of the Nimiq Proof-of-Stake protocol based on the Albatross consensus algorithm. Prior to version 1.5.0, a remote peer can crash any full node by sending a RequestBatchSet message containing the genesis block's hash. The handler calls get_epoch_chunks which iterates backwards through macro blocks using Policy::macro_block_before. When it reaches the genesis block number, macro_block_before panics with "No macro blocks before genesis block". This issue has been patched in version 1.5.0.
🎖@cveNotify
Nimiq is a Rust implementation of the Nimiq Proof-of-Stake protocol based on the Albatross consensus algorithm. Prior to version 1.5.0, a remote peer can crash any full node by sending a RequestBatchSet message containing the genesis block's hash. The handler calls get_epoch_chunks which iterates backwards through macro blocks using Policy::macro_block_before. When it reaches the genesis block number, macro_block_before panics with "No macro blocks before genesis block". This issue has been patched in version 1.5.0.
🎖@cveNotify
GitHub
Fix panic in genesis BatchSet request by jsdanielh · Pull Request #3745 · nimiq/core-rs-albatross
Fixes a panic in RequestBatchSet when requesting the Genesis batch set
🚨 CVE-2026-46545
Nimiq is a Rust implementation of the Nimiq Proof-of-Stake protocol based on the Albatross consensus algorithm. Prior to version 1.5.0, a remote, unauthenticated denial-of-service vulnerability in MerkleRadixTrie::put_chunk allows any state-sync peer to crash any node performing state synchronization (freshly joining nodes and recovering nodes). This issue has been patched in version 1.5.0.
🎖@cveNotify
Nimiq is a Rust implementation of the Nimiq Proof-of-Stake protocol based on the Albatross consensus algorithm. Prior to version 1.5.0, a remote, unauthenticated denial-of-service vulnerability in MerkleRadixTrie::put_chunk allows any state-sync peer to crash any node performing state synchronization (freshly joining nodes and recovering nodes). This issue has been patched in version 1.5.0.
🎖@cveNotify
GitHub
Trie: reject ROOT-keyed items in `put_chunk` by jsdanielh · Pull Request #3762 · nimiq/core-rs-albatross
What's in this pull request?
MerkleRadixTrie::put_chunk processes TrieChunk data from state-sync peers. It validates sorting, key range, and the Merkle proof but does not reject items whose...
MerkleRadixTrie::put_chunk processes TrieChunk data from state-sync peers. It validates sorting, key range, and the Merkle proof but does not reject items whose...
🚨 CVE-2026-47838
SubjectDnX509PrincipalExtractor does not correctly handle certain malformed X.509 certificate CN values, which can lead to reading the wrong value for the username. In a carefully crafted certificate, this can lead to an attacker impersonating another user.
Affected versions:
Spring Security 5.7.0 through 5.7.24; 5.8.0 through 5.8.26; 6.3.0 through 6.3.17; 6.4.0 through 6.4.17; 6.5.0 through 6.5.10.
🎖@cveNotify
SubjectDnX509PrincipalExtractor does not correctly handle certain malformed X.509 certificate CN values, which can lead to reading the wrong value for the username. In a carefully crafted certificate, this can lead to an attacker impersonating another user.
Affected versions:
Spring Security 5.7.0 through 5.7.24; 5.8.0 through 5.8.26; 6.3.0 through 6.3.17; 6.4.0 through 6.4.17; 6.5.0 through 6.5.10.
🎖@cveNotify
Unauthorized User Impersonation when Using X.509 Client Certificates
Level up your Java code and explore what Spring can do for you.
🚨 CVE-2026-53673
BuddyPress 14.4.0 contains an insecure direct object reference vulnerability in the messages REST API that allows authenticated attackers to access arbitrary private message threads by supplying a user_id parameter in the request. Attackers can pass another user's identifier to the get_item_permissions_check method, which validates the supplied user_id instead of the logged-in user and is reused by the update and delete handlers, to read, reply to, or delete any user's private messages.
🎖@cveNotify
BuddyPress 14.4.0 contains an insecure direct object reference vulnerability in the messages REST API that allows authenticated attackers to access arbitrary private message threads by supplying a user_id parameter in the request. Attackers can pass another user's identifier to the get_item_permissions_check method, which validates the supplied user_id instead of the logged-in user and is reused by the update and delete handlers, to read, reply to, or delete any user's private messages.
🎖@cveNotify
🚨 CVE-2026-53674
BuddyPress 14.4.0 contains a regular expression injection vulnerability in the activity mention resolver that, when username compatibility mode is enabled, allows attackers to manipulate a REGEXP database clause by crafting mention names containing regex metacharacters. Attackers can submit @mentions whose metacharacters pass through esc_sql unescaped and are inserted into an unprepared REGEXP query against the users table, enabling boolean-based inference of usernames and denial of service through catastrophic backtracking.
🎖@cveNotify
BuddyPress 14.4.0 contains a regular expression injection vulnerability in the activity mention resolver that, when username compatibility mode is enabled, allows attackers to manipulate a REGEXP database clause by crafting mention names containing regex metacharacters. Attackers can submit @mentions whose metacharacters pass through esc_sql unescaped and are inserted into an unprepared REGEXP query against the users table, enabling boolean-based inference of usernames and denial of service through catastrophic backtracking.
🎖@cveNotify