LiveActive security incident?Get immediate response
CVE archive

May 2026

Browse CVE records published in May 2026, with severity, affected products, CWE, KEV, and source-backed vulnerability context.

Showing 50 of 6036 matching CVEs · Page 33 of 121.

Critical · CVSS 9

CVE-2026-10123: TRENDnet TEW-432BRP formSetDomainFilter stack-based overflow

A vulnerability was found in TRENDnet TEW-432BRP 3.10B20. This impacts the function formSetDomainFilter of the file /goform/formSetDomainFilter. Performing a manipulation of the argument blocked_domain/permitted_domain/blocked_domain_list/permitted_domain_list results in stack-based buffer overflow. It is possible to initiate the attack remotely. The exploit has been made public and could be used. The vendor explains: "This product has been EOL for 15 years (since 2009). As the item has been EOL for such a long time, we are not able to replicate or fix any vulnerabilities." This vulnerability only affects products that are no longer supported by the maintainer.

Published May 30, 2026 · Updated May 30, 2026

Medium · CVSS 5.3

CVE-2026-10116: Open5GS ue-authentications Endpoint ogs-timer.c ogs_sbi_xact_add denial of service

A security flaw has been discovered in Open5GS up to 2.7.7. This vulnerability affects the function ogs_sbi_xact_add in the library /lib/core/ogs-timer.c of the component ue-authentications Endpoint. Performing a manipulation results in denial of service. The attack may be initiated remotely. The exploit has been released to the public and may be used for attacks. Applying a patch is the recommended action to fix this issue.

Published May 30, 2026 · Updated May 30, 2026

High · CVSS 7.1

CVE-2026-46237: drm/amdgpu/vcn3: Avoid overflow on msg bound check

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/vcn3: Avoid overflow on msg bound check As pointed out by SDL, the previous condition may be vulnerable to overflow. (cherry picked from commit db00257ac9e4a51eb2515aaea161a019f7125e10)

Published May 28, 2026 · Updated May 30, 2026

Unknown · CVSS Not scored

CVE-2026-45912: ext4: don't cache extent during splitting extent

In the Linux kernel, the following vulnerability has been resolved: ext4: don't cache extent during splitting extent Caching extents during the splitting process is risky, as it may result in stale extents remaining in the status tree. Moreover, in most cases, the corresponding extent block entries are likely already cached before the split happens, making caching here not particularly useful. Assume we have an unwritten extent, and then DIO writes the first half. [UUUUUUUUUUUUUUUU] on-disk extent U: unwritten extent [UUUUUUUUUUUUUUUU] extent status tree |<- ->| ----> dio write this range First, when ext4_split_extent_at() splits this extent, it truncates the existing extent and then inserts a new one. During this process, this extent status entry may be shrunk, and calls to ext4_find_extent() and ext4_cache_extents() may occur, which could potentially insert the truncated range as a hole into the extent status tree. After the split is completed, this hole is not replaced with the correct status. [UUUUUUU|UUUUUUUU] on-disk extent U: unwritten extent [UUUUUUU|HHHHHHHH] extent status tree H: hole Then, the outer calling functions will not correct this remaining hole extent either. Finally, if we perform a delayed buffer write on this latter part, it will re-insert the delayed extent and cause an error in space accounting. In adition, if the unwritten extent cache is not shrunk during the splitting, ext4_cache_extents() also conflicts with existing extents when caching extents. In the future, we will add checks when caching extents, which will trigger a warning. Therefore, Do not cache extents that are being split.

Published May 27, 2026 · Updated May 30, 2026

Unknown · CVSS Not scored

CVE-2026-45899: ext4: drop extent cache when splitting extent fails

In the Linux kernel, the following vulnerability has been resolved: ext4: drop extent cache when splitting extent fails When the split extent fails, we might leave some extents still being processed and return an error directly, which will result in stale extent entries remaining in the extent status tree. So drop all of the remaining potentially stale extents if the splitting fails.

Published May 27, 2026 · Updated May 30, 2026

Unknown · CVSS Not scored

CVE-2026-45892: ext4: drop extent cache after doing PARTIAL_VALID1 zeroout

In the Linux kernel, the following vulnerability has been resolved: ext4: drop extent cache after doing PARTIAL_VALID1 zeroout When splitting an unwritten extent in the middle and converting it to initialized in ext4_split_extent() with the EXT4_EXT_MAY_ZEROOUT and EXT4_EXT_DATA_VALID2 flags set, it could leave a stale unwritten extent. Assume we have an unwritten file and buffered write in the middle of it without dioread_nolock enabled, it will allocate blocks as written extent. 0 A B N [UUUUUUUUUUUU] on-disk extent U: unwritten extent [UUUUUUUUUUUU] extent status tree [--DDDDDDDD--] D: valid data |<- ->| ----> this range needs to be initialized ext4_split_extent() first try to split this extent at B with EXT4_EXT_DATA_PARTIAL_VALID1 and EXT4_EXT_MAY_ZEROOUT flag set, but ext4_split_extent_at() failed to split this extent due to temporary lack of space. It zeroout B to N and leave the entire extent as unwritten. 0 A B N [UUUUUUUUUUUU] on-disk extent [UUUUUUUUUUUU] extent status tree [--DDDDDDDDZZ] Z: zeroed data ext4_split_extent() then try to split this extent at A with EXT4_EXT_DATA_VALID2 flag set. This time, it split successfully and leave an written extent from A to N. 0 A B N [UUWWWWWWWWWW] on-disk extent W: written extent [UUUUUUUUUUUU] extent status tree [--DDDDDDDDZZ] Finally ext4_map_create_blocks() only insert extent A to B to the extent status tree, and leave an stale unwritten extent in the status tree. 0 A B N [UUWWWWWWWWWW] on-disk extent W: written extent [UUWWWWWWWWUU] extent status tree [--DDDDDDDDZZ] Fix this issue by always cached extent status entry after zeroing out the second part.

Published May 27, 2026 · Updated May 30, 2026

Unknown · CVSS Not scored

CVE-2026-45858: ext4: don't zero the entire extent if EXT4_EXT_DATA_PARTIAL_VALID1

In the Linux kernel, the following vulnerability has been resolved: ext4: don't zero the entire extent if EXT4_EXT_DATA_PARTIAL_VALID1 When allocating initialized blocks from a large unwritten extent, or when splitting an unwritten extent during end I/O and converting it to initialized, there is currently a potential issue of stale data if the extent needs to be split in the middle. 0 A B N [UUUUUUUUUUUU] U: unwritten extent [--DDDDDDDD--] D: valid data |<- ->| ----> this range needs to be initialized ext4_split_extent() first try to split this extent at B with EXT4_EXT_DATA_ENTIRE_VALID1 and EXT4_EXT_MAY_ZEROOUT flag set, but ext4_split_extent_at() failed to split this extent due to temporary lack of space. It zeroout B to N and mark the entire extent from 0 to N as written. 0 A B N [WWWWWWWWWWWW] W: written extent [SSDDDDDDDDZZ] Z: zeroed, S: stale data ext4_split_extent() then try to split this extent at A with EXT4_EXT_DATA_VALID2 flag set. This time, it split successfully and left a stale written extent from 0 to A. 0 A B N [WW|WWWWWWWWWW] [SS|DDDDDDDDZZ] Fix this by pass EXT4_EXT_DATA_PARTIAL_VALID1 to ext4_split_extent_at() when splitting at B, don't convert the entire extent to written and left it as unwritten after zeroing out B to N. The remaining work is just like the standard two-part split. ext4_split_extent() will pass the EXT4_EXT_DATA_VALID2 flag when it calls ext4_split_extent_at() for the second time, allowing it to properly handle the split. If the split is successful, it will keep extent from 0 to A as unwritten.

Published May 27, 2026 · Updated May 30, 2026

High · CVSS 7.5

CVE-2026-10110: code-projects Student Details Management System index.php sql injection

A vulnerability was detected in code-projects Student Details Management System 1.0. This affects an unknown function of the file /index.php. Performing a manipulation of the argument roll results in sql injection. The attack is possible to be carried out remotely. The exploit is now public and may be used.

Published May 30, 2026 · Updated May 30, 2026

High · CVSS 8.5

CVE-2026-44238: FreePBX: Authenticated SQL Injection via ORDER BY in CDR Reports

FreePBX is an open source IP PBX. Prior to 16.0.50 and 17.0.11, the CDR Reports module page allows SQL injection through the order and sort POST parameters. Authentication with a FreePBX Administration Control Panel account that has CDR section access is required. Full administrator privileges are not needed. This vulnerability is fixed in 16.0.50 and 17.0.11.

Published May 29, 2026 · Updated May 30, 2026

High · CVSS 7.6

CVE-2026-44237: FreePBX: Authenticated Access can lead to Subsequent OAuth2 Authentication Bypass in API Module

FreePBX is an open source IP PBX. Prior to 17.0.8, the FreePBX api module's OAuth2 implementation does not sufficiently validate client credentials during token issuance. Knowledge of a valid client_id is required. The validateClient() method in ClientRepository.php unconditionally returns true, allowing any party with knowledge of a valid client_id to obtain OAuth2 access tokens without providing the correct client_secret. This vulnerability is fixed in 17.0.8.

Published May 29, 2026 · Updated May 30, 2026

High · CVSS 7.2

CVE-2026-49095: Improper Input Validation in Kibana Fleet Leading to Privilege Escalation

Improper Input Validation (CWE-20) in the Kibana Fleet agent policy management feature can lead to privilege escalation. An authenticated user with Fleet management privileges can manipulate agent policy configuration by injecting values into a configuration override mechanism that is not adequately validated. An attacker can cause Elastic Agents to be issued API keys with elevated Elasticsearch privileges, potentially granting unauthorized read and write access to sensitive Elasticsearch security indices beyond what is intended for the Fleet management role.

Published May 28, 2026 · Updated May 30, 2026

Critical · CVSS 9.3

CVE-2026-45261: GitButler: Link injection via forge integration enables arbitrary script execution

GitButler is a modern Git-based version control interface for AI-powered workflows. Prior to 0.19.7, a emote code execution vulnerability exists in the Tauri-based GitButler desktop application. An attacker can inject a malicious link in a pull request body, which if clicked by the user allows for arbitrary script execution in the Tauri webview. Users that have not enabled forge integration are not at risk. This vulnerability is fixed in 0.19.7.

Published May 28, 2026 · Updated May 30, 2026