🚨 CVE-2026-90306
In the Linux kernel, the following vulnerability has been resolved:

ARM: 9481/2: breakpoint: CFI breakpoints only on demand

This removes the stub hw_breakpoint_cfi_handler() from ARM, making
it not steal breakpoint type 0x03 (ARM_ENTRY_CFI_BREAKPOINT) unless
CFI is actively used in the kernel.

When not instrumenting with CFI, or when a breakpoint is issued in
userspace, we fall through to return 1 from hw_breakpoint_pending()
"unhandled fault" so userspace can make use of this breakpoint.

Tested with LKDTM and this command line:
echo CFI_FORWARD_PROTO > /sys/kernel/debug/provoke-crash/DIRECT
still works as expected.

🎖@cveNotify

🚨 CVE-2026-90430
In the Linux kernel, the following vulnerability has been resolved:

iommu/tegra241-cmdqv: Publish an LVCMDQ only after it is fully initialized

tegra241_vintf_init_lvcmdq() stores the freshly allocated vcmdq pointer to
the vintf->lvcmdqs[] array, before tegra241_vcmdq_alloc_smmu_cmdq() builds
the vcmdq->cmdq. The error ISR dereferences that cmdq, so a latched LVCMDQ
error (e.g. one inherited across a kexec) firing in this window would make
tegra241_vintf0_handle_error() pass the still-zeroed arm_smmu_cmdq down to
__arm_smmu_cmdq_skip_err(), dereferencing NULL queue register pointers.

Drop the store from tegra241_vintf_init_lvcmdq() and publish the vcmdq at
the end of the allocation instead, with an smp_store_release() that pairs
with an smp_load_acquire() in the ISR, which can see a fully built LVCMDQ
or NULL.

The user-owned LVCMDQ allocation moves accordingly, publishing the vcmdq
once tegra241_vcmdq_hw_init_user() succeeds, using a plain store since a
user VINTF's lvcmdqs[] has no lockless reader -- the error ISR only walks
the VINTF0 array.

🎖@cveNotify

🚨 CVE-2026-93381
Buffer overflow in PDFium in Google Chrome on on Windows prior to 153.0.8010.52 allowed a remote attacker leveraging social engineering to potentially execute arbitrary code inside the sandbox via a crafted PDF file. (Chromium security severity: High)

🎖@cveNotify

🚨 CVE-2026-47321
The CompressionFilter class uses ZLib to deflate and inflate data sent and received. When we inflate incoming data, the filter does not control the resulting size, and create a buffer no matter what.

Some compressed data may have a compression ration greater than 1 thousand, leading to an exhaustion of the application memory, as we don't control the deflated size.




The fix adds such a control by allowing the application developer to provide a fixed size limit, which when reached throws an exception. It also allows the user to provide a compression ratio that should not be exceeded, protected the application from small inflated files that inflate in gigantic files, but with a grace limit for the resulting size (1Mb) to avoid false positive (like a very small file inflating with a high ratio, but resulting with a acceptable size, like a few thousands bytes)




For application using this feature, it is highly recommended to create the CompressionFilter and to pass the maximum limit as a forth constructor parameter, maxDecompressedSize:




public CompressionFilter(final boolean compressInbound, final boolean compressOutbound, final int compressionLevel, final int maxDecompressedSize)Optionally one can also provide a maxDecompressRatio fifth parameter, and a decompressRatioMinSize sixth parameter to allow small inflated files with a high compression ratio to still be accepted.




Here are the additional constructor:






public CompressionFilter(final boolean compressInbound, final boolean compressOutbound,



final int compressionLevel, final int maxDecompressedSize,



final long maxDecompressRatio, final long decompressRatioMinSize)








Also note that a fluent API has been added to spare the users the pain to call a constructor with that many parameters:






 CompressionFilter compressionFilter = new CompressionFilter()

    .setCompressionLevel(Zlib.COMPRESSION_MAX)

  .setMaxDecompressedSize(1_000_000)

  .setMaxDecompressRatio(100).

  .setDecompressRatioMinSize(100_000); 









Applications using Apache MINA are advised to upgrade and configure their CompressionFilter instance.

🎖@cveNotify

🚨 CVE-2025-12999
UrlUtil.getBaseUrl builds the absolute URLs in a response — download links, icons, asset and API URLs — from the X-Forwarded-Host, X-Forwarded-Proto and X-Forwarded-Prefix request headers, with no check on whether the sender was a trusted proxy, falling back to the client-supplied Host header.




Those responses are cached under keys that do not include the host (extension.json since 0.6.0, namespace.details.json since 0.9.0, sitemap since 0.14.5, latest.extension.version.vscode since 0.34.2). A single request carrying a forged header therefore places attacker-chosen URLs into an entry served to every other client for the lifetime of that entry — one hour by default, and cluster-wide where ovsx.redis.enabled is set.



The VSIX download URL, its signature URL and the public key URL are all derived from the same base URL, so extension signing does not limit the impact: an attacker who poisons an entry supplies the package, the signature over it, and the key used to verify it.



Exploitability depends on deployment topology. A server reachable directly by clients, or fronted by a proxy that relays the client's X-Forwarded-Host rather than overwriting it, is exploitable by an unauthenticated remote attacker. A proxy that overwrites the header is not.



An unauthenticated attacker can poison Open VSX's per-extension metadata cache with attacker-controlled download, signature, and public-key URLs by supplying a crafted X-Forwarded-Host header, causing downstream VS Code-compatible editors to fetch and install a malicious VSIX.



Workarounds (unpatched versions)




1. Configure the reverse proxy to set rather than relay X-Forwarded-Host, X-Forwarded-Proto and X-Forwarded-Prefix — note that nginx's $host is the client's Host header and is not a safe value.



2. Ensure the server is not reachable except through that proxy.



3. Flush the caches afterwards; poisoned entries survive the configuration change.

🎖@cveNotify

🚨 CVE-2026-85010
The RestroPress WordPress plugin before 3.4.6 does not validate a client-supplied item add-on price on the server side when items are added to or updated in the cart, allowing unauthenticated users to set an arbitrary price and place orders for an attacker-chosen total, down to and including zero.

🎖@cveNotify

🚨 CVE-2026-86802
The To Do List Member WordPress plugin through 1.6 does not have authorisation or nonce checks in an import routine, and does not validate the location it fetches the imported data from, allowing unauthenticated users to create arbitrary published posts and taxonomy terms on the site.

🎖@cveNotify

🚨 CVE-2026-91863
A specially crafted WS-Policy document with deeply nested policy elements can bypass Neethi's nesting-depth limit and exhaust the thread stack, crashing the parser (denial of service).
Users are recommended to upgrade to version 3.2.4, which fixes this issue.

🎖@cveNotify

🚨 CVE-2026-91864
A specially crafted WS-Policy document can pack unlimited content inside a policy assertion, which Neethi copies into memory without counting it against its size limits, exhausting the heap (denial of service).
Users are recommended to upgrade to version 3.2.4, which fixes this issue.

🎖@cveNotify

🚨 CVE-2026-91865
A small WS-Policy document using repeated policy references can force Neethi to re-expand the same references exponentially during normalization, consuming huge amounts of CPU and memory (denial of service).
Users are recommended to upgrade to version 3.2.4, which fixes this issue.

🎖@cveNotify

🚨 CVE-2026-91866
A specially crafted pair of WS-Policy documents can force Neethi's policy-intersection to do exponential amounts of work, pinning the CPU for a long time (denial of service).
Users are recommended to upgrade to version 3.2.4, which fixes this issue.

🎖@cveNotify

🚨 CVE-2026-91867
When Neethi fetches a remote policy reference, it only limits the time per read, not the whole transfer, so a server that trickles bytes slowly can keep the fetch alive indefinitely and tie up the calling thread (denial of service).
Users are recommended to upgrade to version 3.2.4, which fixes this issue.

🎖@cveNotify

🚨 CVE-2025-71419
UVdesk core-framework before 1.1.7 contains a stored cross-site scripting vulnerability in the SwiftMailer configuration identifier parameter of the createMailerConfiguration action. Attackers with ROLE_AGENT can inject malicious script into the identifier field, which is persisted and executed when other members access the configuration update page.

🎖@cveNotify

🚨 CVE-2025-71420
UVdesk core-framework before 1.1.7 contains an authorization bypass vulnerability in the saved reply endpoint that allows authenticated agents to access replies restricted to other support groups. Attackers with ROLE_AGENT can enumerate saved reply identifiers and read content reserved for groups and teams they do not belong to.

🎖@cveNotify

🚨 CVE-2025-71421
UVdesk core-framework before 1.1.7 contains an improper privilege management vulnerability in the editAgent endpoint that allows agents with agent-management privilege to escalate their own role to administrator. Attackers can submit their own account identifier with a role parameter set to ROLE_ADMIN to gain full administrative control over agents, tickets, and mail configuration.

🎖@cveNotify

🚨 CVE-2026-85220
A vulnerability in the Thinkst Canary honeypot Redis service allows an unauthenticated remote attacker to execute a Denial-of-Service attack against the honeypot.

The vulnerability is accessible when the Redis service is enabled only.

The Canary is NOT affected if the Redis service is disabled.

Thinkst has addressed this issue on all supported platforms.

New update files to address this issue are available on all platforms except Docker. For Docker customers, a new Docker image has been published which includes the patch. Customers with automatic updates enabled already have updates in distribution. If automatic updates are disabled, customers are advised to update their Canaries.

Workarounds are available for customers unable to update at this time.

🎖@cveNotify

🚨 CVE-2026-88806
A malicious X server could exploit a buffer overflow in libX11 before 1.8.14 during handling of XkbGetMap overflowing the key_sym_map.

🎖@cveNotify

🚨 CVE-2026-88807
A heap overflow in libXrender before 0.9.13 in RenderQueryPictFormats could be used by malicious X servers to inject code into attached X clients.

🎖@cveNotify

🚨 CVE-2026-94382
Beszel before 0.19.0 contains an insecure direct object reference vulnerability in the POST and DELETE /api/beszel/user-alerts handlers that allows any authenticated user to create or delete alerts on systems they cannot access. Attackers can supply arbitrary system IDs in the request body to register alert rules and receive notifications disclosing target system names and metrics.

🎖@cveNotify

🚨 CVE-2026-94387
Aureus ERP before 1.6.0 contains a stored cross-site scripting vulnerability in the Chatter field-change log where old_value and new_value entries are rendered without proper escaping. Any user permitted to edit tracked text fields can inject malicious markup that executes when other users, including administrators, view the record's Chatter panel.

🎖@cveNotify

🚨 CVE-2026-94393
When a user creates or edits a report inside an event, MISP can identify an existing report using its UUID without properly checking whether that report actually belongs to the same event.

As a result, a user who has editing rights on one event could potentially move a report from another event into their own event, as long as they know or can guess the report’s UUID. Once moved, they could view and change information that they were not originally allowed to access.

The vulnerability requires the attacker to have editor access to at least one event and to know or discover a valid report UUID.

The main impact is that private event reports could be exposed or modified across event boundaries, bypassing MISP’s normal access restrictions.

Version affected: <2.5.47

🎖@cveNotify