Information Disclosure
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
How It Works
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security. This happens through multiple channels: verbose error messages that display stack traces revealing internal paths and frameworks, improperly secured debug endpoints left active in production, and misconfigured servers that expose directory listings or version control artifacts like .git folders. APIs often leak excessive data in responses—returning full user objects when only a name is needed, or revealing system internals through metadata fields.
Attackers exploit these exposures systematically. They probe for common sensitive files (.env, config.php, backup archives), trigger error conditions to extract framework details, and analyze response timing or content differences to enumerate valid usernames or resources. Even subtle variations—like "invalid password" versus "user not found"—enable account enumeration. Exposed configuration files frequently contain database credentials, API keys, or internal service URLs that unlock further attack vectors.
The attack flow typically starts with passive reconnaissance: examining HTTP headers, JavaScript bundles, and public endpoints for version information and architecture clues. Active probing follows—testing predictable paths, manipulating parameters to trigger exceptions, and comparing responses across similar requests to identify information leakage patterns.
Impact
- Credential compromise: Exposed configuration files, hardcoded secrets in source code, or API keys enable direct authentication bypass
- Attack surface mapping: Stack traces, framework versions, and internal paths help attackers craft targeted exploits for known vulnerabilities
- Data breach: Direct exposure of user data, payment information, or proprietary business logic through oversharing APIs or accessible backups
- Privilege escalation pathway: Internal URLs, service discovery information, and architecture details facilitate lateral movement and SSRF attacks
- Compliance violations: GDPR, PCI-DSS, and HIPAA penalties for exposing regulated data through preventable disclosures
Real-World Examples
A major Git repository exposure affected thousands of websites when .git folders remained accessible on production servers, allowing attackers to reconstruct entire source code histories including deleted commits containing credentials. Tools like GitDumper automated mass exploitation of this misconfiguration.
Cloud storage misconfigurations have repeatedly exposed sensitive data when companies left S3 buckets or Azure Blob containers publicly readable. One incident exposed 150 million voter records because verbose API error messages revealed the storage URL structure, and no authentication was required.
Framework debug modes left enabled in production have caused numerous breaches. Django's DEBUG=True setting exposed complete stack traces with database queries and environment variables, while Laravel's debug pages revealed encryption keys through the APP_KEY variable in environment dumps.
Mitigation
- Generic error pages: Return uniform error messages to users; log detailed exceptions server-side only
- Disable debug modes: Enforce production configurations that suppress stack traces, verbose logging, and debug endpoints through deployment automation
- Access control audits: Restrict or remove development artifacts (
.git, backup files,phpinfo()) and internal endpoints before deployment - Response minimization: API responses should return only necessary fields; implement allowlists rather than blocklists for data exposure
- Security headers: Deploy
X-Content-Type-Options, remove server version banners, and disable directory indexing - Timing consistency: Ensure authentication and validation responses take uniform time regardless of input validity
Recent CVEs (66662)
Author spoofing in NodeBB's ActivityPub federation allows a remote federated actor to forge posts and private messages attributed to arbitrary local users, including the administrator (uid 1). Because the inbound middleware validates the HTTP-signature actor and the origin of object.id but never binds attributedTo to the authenticated sender, an attacker with a valid remote signature can impersonate any local account. Publicly available exploit code exists (reported by VulnCheck), though there is no public exploit identified in CISA KEV and the flaw only affects instances with federation enabled.
Cross-user attribute structure leakage in API Platform Core's JSON:API and HAL serializers exposes the schema layout of security-gated properties to lower-privileged users through improper cache reuse. Versions from 2.6.0 up to 4.1.29, 4.2.26, and 4.3.12 are affected across the core, hal, and json-api packages. The component structure computed for a higher-privileged user's request can be served from cache to a subsequent lower-privileged user's request, bypassing the per-request evaluation of #[ApiProperty(security: ...)] predicates. No public exploit identified at time of analysis; vendor-released patches are available.
Type confusion in API Platform Core's AbstractItemNormalizer allows authenticated API consumers to corrupt relational data by supplying IRIs pointing to resources of the wrong type during write operations (POST/PUT/PATCH). The root cause is that getResourceFromIri() omits the $operation context when calling IriConverter::getResourceFromIri(), silently bypassing the is_a type guard at IriConverter.php:86. All 4.1.x, 4.2.x, and 4.3.x releases prior to the patched versions are affected; no public exploit or CISA KEV listing has been identified at time of analysis.
Heap buffer over-write in ImageMagick's JP2 (JPEG 2000) encoder - present in all versions prior to 7.1.2-26 - allows an attacker to crash the process by supplying a maliciously crafted JP2 image file, resulting in a denial-of-service condition. The root cause is CWE-682 (Incorrect Calculation): argument handling logic in the JP2 encoder computes incorrect bounds, leading to an out-of-bounds heap write. No public exploit code has been identified at time of analysis, and the vulnerability is not listed in the CISA KEV catalog.
Repomix 1.14.0's MCP server exposes a file-read safety bypass allowing any MCP-connected client to retrieve arbitrary local `.json`, `.txt`, `.md`, or `.xml` files without triggering the project's `runSecretLint()` secret-scanning guard. The `attach_packed_output` tool accepts arbitrary local paths, validates only by file extension, reads the file without invoking the secret check, and registers the path under an `outputId`; `read_repomix_output` then returns the full file contents-entirely circumventing the boundary enforced by the dedicated `file_system_read_file` tool. No CISA KEV listing or EPSS data is available, but the advisory includes a reproduction harness that confirmed the bypass end-to-end against repomix@1.14.0.
Use-after-free in ImageMagick's 8BIM profile parser crashes the process when a specially crafted image is identified, affecting all releases prior to 6.9.13-51 (legacy branch) and 7.1.2-26 (current branch). The vulnerability is triggered by a specific format string embedded in the 8BIM metadata profile, causing memory corruption that results in a denial-of-service condition. No public exploit or CISA KEV listing has been identified at time of analysis; EPSS data was not provided in the intelligence feed.
Heap memory disclosure in ImageMagick's MNG decoder affects all versions prior to 6.9.13-51 (legacy branch) and 7.1.2-26 (current branch), allowing remote unauthenticated attackers to obtain partial heap contents by submitting a crafted MNG image file and retrieving the processed output. The root cause (CWE-908) is that pixel buffers are not fully initialized before output is written, leaving residual in-process heap data embedded in the resulting image. No public exploit or CISA KEV listing exists at time of analysis; however, the zero-authentication, network-accessible attack vector makes this a meaningful risk for any image-processing pipeline that accepts untrusted MNG input.
Local privilege escalation in Dell Device Management Agent (DDMA) versions prior to 26.05 allows an already-authenticated, low-privileged user on the host to elevate to full system-level control by abusing insecure symbolic/hard link resolution (CWE-59) during file operations. Dell has released a fix in DDMA 26.05. There is no public exploit identified at time of analysis and EPSS estimates exploitation probability at only 0.12% (3rd percentile), but the SSVC technical impact is rated 'total', reflecting the complete compromise achievable once a foothold exists.
Credential exposure in AWS CLI on Unix-like systems allows other local users on the same host to read sensitive credentials written to disk by three specific subcommands: aws codeartifact login, aws iam create-virtual-mfa-device, and aws deploy register. When the system umask is at its default permissive value - the case on most Unix-like systems - credential files are written without adequately restrictive permissions, making them readable by other local accounts. No public exploit or CISA KEV listing exists at time of analysis; however, the vendor (Amazon) has confirmed the issue and released patched versions 1.44.78 (v1) and 2.34.29 (v2).
Policy bypass in ImageMagick's `-concatenate` operation allows local users to read from and write to filesystem paths that the configured security policy explicitly prohibits. All versions prior to 7.1.2-26 are affected. An attacker or unprivileged local user can invoke ImageMagick with `-concatenate` to circumvent path-based access controls defined in ImageMagick's policy.xml, effectively nullifying a primary hardening control relied upon in restricted or multi-tenant deployments. No public exploit code or CISA KEV listing is identified at time of analysis.
Authorization bypass and information disclosure in GeoNetwork 4.x (4.0.0-alpha.1 through 4.4.10) lets an unauthenticated remote user retrieve restricted metadata records through the Elasticsearch-backed search API. Under certain request conditions the proxy layer skips the step that injects GeoNetwork's access-control filters, so requests reach the index without group-visibility, ownership, draft-exclusion, or portal filtering applied. There is no public exploit identified at time of analysis, but the flaw is unauthenticated and network-reachable on any public-facing instance, making disclosure of non-public catalog records trivial once the triggering condition is known.
### Summary A memory-safety vulnerability in Open Babel's PQS parser caused an uninitialized pointer dereference when reading a crafted input file. Rated high severity (CVSS 7.8), this vulnerability is no authentication required, low attack complexity.
### Summary A memory-safety vulnerability in Open Babel's MSI parser caused an uninitialized pointer dereference when reading a crafted input file. Rated high severity (CVSS 7.8), this vulnerability is no authentication required, low attack complexity.
### Summary A memory-safety vulnerability in Open Babel's GRO parser caused an uninitialized pointer dereference when reading a crafted input file. Rated high severity (CVSS 7.8), this vulnerability is no authentication required, low attack complexity.
Sensitive data exposure in the HubSpot (Leadin) WordPress plugin versions up to and including 11.3.51 allows a low-privileged authenticated user to retrieve embedded sensitive information that is inserted into data sent by the plugin. Reported by Patchstack and tracked as CWE-201 with a CVSS 7.4 (scope-changed), there is no public exploit identified at time of analysis and it is not listed in CISA KEV. The realistic impact is limited to information disclosure of secrets or private data the plugin transmits, without evidence of widespread or automated exploitation.
Incorrect Authorization (CWE-863) in Elastic Defend exposes response action data to low-privileged authenticated users who should not have access to it. The flaw, classified under CAPEC-1, arises because access controls on specific functionality are not properly enforced, allowing a user with minimal privileges to read security response action data belonging to other users or roles. No public exploit code has been identified and the vulnerability is not listed in the CISA KEV catalog, but the High confidentiality impact (CVSS C:H) means sensitive endpoint response data - such as isolation actions, process kills, or file retrieval outputs - could be disclosed.
Sensitive HTTP request header values are written into Kibana application logs when the optional APM (Application Performance Monitoring) instrumentation feature is enabled, exposing credentials or tokens to anyone with operator-level log access. This affects multiple Kibana release branches (8.18.x, 8.19.x, 9.0.x, and 9.1.x) and is classified as information disclosure under CWE-532. No public exploit or active exploitation has been identified at time of analysis; the exposure is passive and gated behind both a non-default configuration and existing operator privileges.
Arbitrary HDF5 file read in Keras up to 3.13.2 enables information disclosure when a victim loads a crafted model file, representing an incomplete patch for the prior CVE-2026-1669. The flaw lies in two specific code paths - `H5IOStore._verify_dataset()` and `file_editor.py` - which omit the `dataset.is_virtual` check, allowing a malicious HDF5 Virtual Dataset (VDS) to silently redirect reads to attacker-specified paths on the local filesystem. No public exploit code has been identified at time of analysis, and this vulnerability is not listed in the CISA KEV catalog, but the attack surface is realistic in ML supply chain and model-sharing contexts.
The genucenter web interface by genua exposes SNMP authentication and encryption keys in cleartext HTTP responses to any user holding the 'Service' or 'Admin' role, enabling credential theft without any exploitation complexity beyond normal authenticated use. Affected versions are all releases prior to 8.0p11; the fix was disclosed by sba-research via a coordinated advisory in April 2026. No public exploit code or active exploitation has been identified at time of analysis, though the disclosure of SNMP v3 keys - which govern both authentication integrity and traffic encryption - represents a meaningful lateral movement risk if those keys are reused across network devices.
Authentication bypass in NVIDIA AIStore, a scalable distributed object-storage framework for AI/ML data pipelines, lets a remote attacker circumvent access controls (CWE-290) and reach protected functionality without valid credentials. Because the flaw yields full confidentiality, integrity, and availability impact (CVSS 9.8), successful exploitation can enable information disclosure of stored datasets, tampering with training data, privilege escalation, and denial of service. There is no public exploit identified at time of analysis and the CVE is not listed in CISA KEV.
Information disclosure in MediaWiki's core parser component (includes/Parser/Parser.php) allows authenticated low-privilege users, under conditions requiring user interaction, to obtain sensitive information not intended for their access level. All MediaWiki branches are affected up to versions 1.43.9, 1.44.6, 1.45.4, and 1.46.0, covering a broad installation base including self-hosted wikis worldwide. No public exploit code exists and no active exploitation has been confirmed at time of analysis; however, the provided CVSS 4.0 vector contains a contradictory zero-impact scoring that warrants independent verification against the upstream advisory.
Sensitive abuse filter configuration data in Wikimedia Foundation's AbuseFilter MediaWiki extension is exposed to authenticated low-privilege users via the QueryAbuseFilters API endpoint (includes/Api/QueryAbuseFilters.php). Authenticated wiki users on affected installations (all versions before 1.46.0, 1.45.4, 1.44.6, and 1.43.9) can retrieve private or restricted filter rule details they should not be authorized to access. No active exploitation has been confirmed (not listed in CISA KEV) and no public proof-of-concept exploit is known at time of analysis, but the moderate CVSS 4.0 score of 5.3 reflects real risk to wikis relying on confidential filter logic for abuse prevention.
Local code execution and privilege escalation in NVIDIA Megatron Bridge (Linux) stems from unsafe handling of dynamically managed code resources, rooted in an insecure deserialization flaw (CWE-502). A low-privileged local user who can influence the data or model artifacts Megatron Bridge loads can achieve arbitrary code execution, escalate privileges, tamper with data, and disclose information. NVIDIA self-reported the issue with a CVSS 3.1 base score of 7.8; there is no public exploit identified at time of analysis and it is not listed in CISA KEV.
Local privilege escalation and code execution in NVIDIA Megatron Bridge for Linux stems from unsafe deserialization of attacker-controlled input (CWE-502), allowing a low-privileged local user to achieve arbitrary code execution, tamper with data, and disclose information. NVIDIA reported the flaw with no public exploit identified at time of analysis, and it is not listed in CISA KEV; no EPSS score was provided. Megatron Bridge is an ML/LLM training framework, so impact centers on shared GPU/training hosts rather than internet-facing services.
Deserialization of untrusted data in NVIDIA Megatron Bridge for Linux allows a low-privileged local attacker to achieve code execution, privilege escalation, data tampering, and information disclosure. Megatron Bridge is NVIDIA's model-interoperability tooling used to convert and load large-language-model checkpoints in the Megatron/PyTorch training stack, where unsafe object deserialization (CWE-94) lets attacker-controlled serialized data run arbitrary code in the process context. There is no public exploit identified at time of analysis and it is not listed in CISA KEV, but the CVSS 7.8 (High) rating with full C/I/A impact makes it a meaningful risk on shared or multi-tenant ML infrastructure.
Arbitrary code execution in NVIDIA Megatron Bridge for Linux stems from improper control of code generation (CWE-94), allowing an attacker who convinces a user to process a malicious artifact to run code in the context of the training/inference workload. Successful exploitation can escalate privileges, tamper with data, and disclose information. There is no public exploit identified at time of analysis, and the flaw is not listed in CISA KEV; the CVSS 3.1 vector (AV:L/UI:R) indicates local access with user interaction is required.
Insecure deserialization in NVIDIA Megatron Bridge for Linux (CWE-502) lets an attacker who supplies a crafted serialized object achieve code execution, privilege escalation, data tampering, and information disclosure when a local user loads that data. The CVSS 3.1 vector (AV:L/AC:L/PR:N/UI:R) shows the attack is local and hinges on the victim opening attacker-controlled content, with no public exploit identified at time of analysis. Megatron Bridge is a specialized NVIDIA library for bridging large-language-model training frameworks, so exposure is concentrated in ML/AI training and research environments rather than general enterprise fleets.
Arbitrary code execution in NVIDIA Megatron Bridge on Linux arises from unsafe reflection (CWE-470), where externally-controlled input selects which classes or code resources are dynamically loaded. A local attacker who convinces a user to load a crafted artifact (e.g., a malicious model, checkpoint, or configuration) can trigger code execution, privilege escalation, data tampering, and information disclosure. There is no public exploit identified at time of analysis, and it is not listed in CISA KEV.
Arbitrary code execution in NVIDIA Megatron Bridge for Linux arises from unsafe deserialization of untrusted data (CWE-502), allowing an attacker who tricks a user into loading a crafted serialized object to execute code, escalate privileges, tamper with data, and disclose information. The flaw affects the Megatron Bridge model-conversion/training tooling and is locally exploitable but hinges on victim interaction (UI:R). No public exploit code has been identified and the issue is not in CISA KEV, so there is currently no evidence of active exploitation.
Sensitive information exposure in MediaWiki's InfoAction.php allows unauthenticated remote actors to obtain restricted page metadata through the 'Info' action endpoint. All MediaWiki versions before 1.46.0, 1.45.4, 1.44.6, and 1.43.9 are affected across all deployment configurations. No public exploit code exists and the vulnerability is not listed in CISA KEV, but the low attack complexity and lack of authentication requirements make opportunistic discovery straightforward for any actor who can reach the wiki.
Arbitrary code execution and privilege escalation in NVIDIA Megatron Bridge on Linux arises from unsafe deserialization of untrusted data, allowing a local attacker who convinces a user to load a malicious serialized object to run code, tamper with data, and disclose information. NVIDIA (the reporting vendor) rates it 7.8 (High); the CVSS vector requires local access and user interaction, so exploitation is not remote-unauthenticated. There is no public exploit identified at time of analysis and it is not listed in CISA KEV.
Administrative access to the Stormshield Network Security captive-admin portal is bypassed when an attacker presents a revoked client certificate, because the portal does not enforce certificate revocation checks during TLS mutual authentication. Affected versions span three branches: 4.3.0-4.3.41, 4.4.0-4.8.15, and 5.0.2 EA-5.0.5. No public exploit has been identified at time of analysis and the vulnerability is absent from CISA KEV, but the threat actor population is meaningfully constrained - exploitation requires prior possession of a certificate that was specifically issued for this portal and then revoked.
Arbitrary code execution in NVIDIA Megatron Bridge (all versions per the NVIDIA advisory) arises from unsafe deserialization of untrusted data (CWE-502), where an attacker supplies a crafted serialized object — typically a malicious model checkpoint or configuration artifact — that a user loads locally, yielding code execution, privilege escalation, data tampering, and information disclosure. The CVSS 3.1 base score is 7.8 (High) with a local vector requiring user interaction (AV:L/UI:R) and no attacker privileges. There is no public exploit identified at time of analysis and it is not listed in CISA KEV; no EPSS score was provided.
Server-side request forgery in NVIDIA Megatron Bridge for Linux allows an attacker to coerce the software into issuing attacker-controlled requests, potentially leading to disclosure of sensitive information. The flaw (CWE-918) was reported by NVIDIA itself and carries a vendor CVSS 3.1 score of 7.8; notably the vector is scored as local with required user interaction (AV:L/UI:R) rather than a classic remote SSRF, which security teams should reconcile against the SSRF classification. There is no public exploit identified at time of analysis and it is not listed in CISA KEV.
Insufficient permission enforcement in MediaWiki's user query API endpoints allows low-privileged authenticated users to access sensitive user information - such as group memberships or account details - that permission controls should restrict. The vulnerability spans four source files: ApiQueryAllUsers.php, ApiQueryUsers.php, PermissionManager.php, and UserGroupManager.php, indicating that the flaw lies in how permission checks are applied (or bypassed) when the API serializes user data. No public exploit code exists and the CVSS 4.0 score of 2.1 reflects the constrained real-world exploitability. No confirmed active exploitation (CISA KEV) has been reported.
Deserialization of untrusted data in NVIDIA Megatron Bridge for Linux (CWE-502) can lead to arbitrary code execution, privilege escalation, data tampering, and information disclosure when a user loads attacker-controlled data. The CVSS 3.1 vector (AV:L/AC:L/PR:N/UI:R) indicates a local attack requiring the victim to open or process a malicious artifact — consistent with unsafe deserialization of a model checkpoint, config, or serialized object. There is no public exploit identified at time of analysis and the CVE is not listed in CISA KEV; EPSS was not provided.
HTML::Gumbo versions before 0.19 for Perl disclose heap memory via type confusion. Support for the <template> element was added to libgumbo 0.10.0 in 2015, but the walk_tree function in lib/HTML/Gumbo.xs was not updated to support it. The element was treated as a text-node, where strlen() over-reads the heap block that the pointer addresses. Any caller that runs parse() with the default format => 'string', or with format => 'tree', on input containing a <template> element serializes the over-read bytes into the returned result, disclosing bounded heap contents. format => 'callback' reaches a croak on the unhandled node type and is unaffected.
Information disclosure in MediaWiki's ApiUserrights.php exposes sensitive user rights data to authenticated actors who should not have access to it. All MediaWiki installations running versions prior to 1.43.9, 1.44.6, 1.45.4, and 1.46.0 are affected. The CVSS 4.0 score of 5.1 with low confidentiality impact (VC:L) reflects a bounded but real data leakage risk; no public exploit identified at time of analysis.
Session fixation in the Wikimedia Foundation OAuth MediaWiki extension (src/Backend/MWOAuthServer.php) allows a network-accessible, low-privileged attacker to manipulate the OAuth authorization handshake so that a victim's authentication binds to an attacker-controlled session identifier. All four actively maintained release branches are affected through versions 1.46.0, 1.45.4, 1.44.6, and 1.43.9. No public exploit or CISA KEV listing exists at time of analysis; however, the 'Information Disclosure' tag applied to this CVE creates tension with the vendor-supplied CVSS 4.0 zero-impact scoring and warrants independent verification.
Improper input validation in Wikimedia Foundation's UrlShortener extension (includes/UrlShortenerUtils.php) exposes a potential information disclosure path accessible to low-privileged authenticated users over the network. The vulnerability is classified under CWE-20 and tagged as an information disclosure issue, though the provided CVSS 4.0 vector records zero impact across all dimensions - a notable contradiction with the 'Information Disclosure' tag that warrants independent verification. No public exploit code exists and no active exploitation has been confirmed.
Cross-tenant information disclosure in Foreman (packaged as Red Hat Satellite 6) allows an authenticated user holding host-edit permissions to retrieve sensitive infrastructure metadata from organizations and locations they are not authorized to access. The root cause is the taxonomy_scope controller method accepting organization and location IDs from nested request parameters without validating them against the caller's authorized tenancy scope, implementing a textbook CWE-639 authorization bypass through user-controlled key. No active exploitation has been confirmed (not listed in CISA KEV), and no public exploit code is identified at time of analysis; however, the low attack complexity and lack of user interaction make this straightforward to exploit for any low-privileged authenticated user in multi-tenant Satellite deployments.
Private SSH key exfiltration in Red Hat Satellite 6 (upstream: Foreman) allows authenticated users holding the 'view_keypairs' permission to bypass taxonomy scoping and retrieve private SSH keys belonging to foreign organizations by directly querying key pair IDs via the API. The flaw is an IDOR (CWE-639) at the multi-tenancy enforcement layer, meaning the isolation contract between tenant organizations is broken for any user granted that permission. No CISA KEV listing or public exploit code has been identified at time of analysis; impact is strictly confidentiality - no write or destructive capability is exposed through this path.
Uninitialized cluster exposure in FatFs R0.16 and earlier allows recovery of residual disk data when f_lseek() extends a file beyond its current EOF without zeroing newly allocated FAT clusters. Any application or device reading the extended region receives raw, previously written sector content instead of zeroed bytes, leaking sensitive residual storage data such as deleted file fragments or cryptographic material. A proof-of-concept exploit exists per SSVC and runZero's GitHub repository; no active exploitation has been confirmed in CISA KEV.
Integer underflow in FatFs R0.16 and earlier corrupts filesystem integrity via a stale dirty-cache skip during interleaved read/write operations on fragmented volumes. The condition `fp->sect - sect < cc` in f_read() and f_write() uses unsigned arithmetic - when `sect` exceeds `fp->sect`, the subtraction wraps to a large unsigned value, bypassing the required cache flush and leaving stale or inconsistent data on disk. A proof-of-concept exists per SSVC assessment, and technical impact is rated Total, though physical access is required per the CVSS vector. No confirmed active exploitation (not in CISA KEV).
Divide-by-zero in FatFs R0.16 and earlier's exFAT sync logic crashes the filesystem when crafted volume metadata causes the expression `n_fatent - 2` to evaluate to zero during write/sync operations, resulting in a hard fault or denial of service on the affected embedded device. The elm-chan FatFs library is widely bundled into microcontroller SDKs and IoT firmware, meaning the vulnerable code exists across a broad range of downstream products compiled with exFAT support. A proof-of-concept exists per SSVC assessment; no confirmed active exploitation (CISA KEV) has been recorded, and the physical attack vector limits mass exploitation, though network-accessible firmware update pipelines can extend effective reach.
In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Fix phys BO pread/pwrite with offset sg_page() returns struct page pointer not (void *) so the scaling of pread/pwrite is wrong for phys BO and wrong parts of BO would be accessed if non-zero offset is used. Last impacted platform with overlay or cursor planes using phys mapping was Gen3/945G/Lakeport. (cherry picked from commit 3e49a2f85070b2fb672c1e0fdba281a4ea3aebe6)
In the Linux kernel, the following vulnerability has been resolved: net: rds: clear i_sends on setup unwind The RDS IB connection teardown path is written so it can run during partial startup and on repeated shutdown attempts. It uses NULL pointers to distinguish resources that are still owned from resources that have already been released. When rds_ib_setup_qp() fails after allocating i_sends but before allocating i_recvs, the sends_out path frees i_sends without clearing the pointer. A later shutdown pass can still treat that stale pointer as a live send ring allocation. Clear i_sends after vfree() in the error unwind path so the existing shutdown logic continues to use the correct ownership state.
In the Linux kernel, the following vulnerability has been resolved: arm64: errata: Mitigate TLBI errata on various Arm CPUs A number of CPUs developed by Arm suffer from errata whereby a broadcast TLBI;DSB sequence may complete before the global observation of writes which are translated by an affected TLB entry. These errata ONLY affect the completion of memory accesses which have been translated by an invalidated TLB entry, and these errata DO NOT affect the actual invalidation of TLB entries. TLB entries are removed correctly. This issue has been assigned CVE ID CVE-2025-10263. To mitigate this issue, Arm recommends that software follows any affected TLBI;DSB sequence with an additional TLBI;DSB, which will ensure that all memory write effects affected by the first TLBI have been globally observed. The additional TLBI can use any operation that is broadcast to affected CPUs, and the additional DSB can use any option that is sufficient to complete the additional TLBI. The ARM64_WORKAROUND_REPEAT_TLBI workaround is sufficient to mitigate the issue. Enable this workaround for affected CPUs, and update the silicon errata documentation accordingly. Note that due to the manner in which Arm develops IP and tracks errata, some CPUs share a common erratum number.
In the Linux kernel, the following vulnerability has been resolved: hsr: Remove WARN_ONCE() in hsr_addr_is_self(). syzbot reported the warning [0] in hsr_addr_is_self(), whose assumption is simply wrong. hsr->self_node is cleared in hsr_del_self_node(), which is called from hsr_dellink(). Since dev->rtnl_link_ops->dellink() is called before unregister_netdevice_many(), there is a window when user can find the device but without hsr->self_node. Let's remove WARN_ONCE() in hsr_addr_is_self(). [0]: HSR: No self node WARNING: net/hsr/hsr_framereg.c:39 at hsr_addr_is_self+0x211/0x3f0 net/hsr/hsr_framereg.c:39, CPU#0: syz.4.16848/17220 Modules linked in: CPU: 0 UID: 0 PID: 17220 Comm: syz.4.16848 Tainted: G L syzkaller #0 PREEMPT_{RT,(full)} Tainted: [L]=SOFTLOCKUP Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/18/2026 RIP: 0010:hsr_addr_is_self+0x211/0x3f0 net/hsr/hsr_framereg.c:39 Code: 33 2f 41 0f b7 dd 89 ee 09 de 31 ff e8 c8 b4 c6 f6 09 dd 74 54 e8 0f b0 c6 f6 31 ed eb 53 e8 06 b0 c6 f6 48 8d 3d 2f 50 9c 04 <67> 48 0f b9 3a 31 ed eb 42 e8 c1 13 1f 00 89 c5 31 ff 89 c6 e8 96 RSP: 0018:ffffc900041c70e0 EFLAGS: 00010283 RAX: ffffffff8afdc6ca RBX: ffffffff8afdc4e6 RCX: 0000000000080000 RDX: ffffc90010493000 RSI: 0000000000000948 RDI: ffffffff8f9a1700 RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 R10: ffffc900041c71e8 R11: fffff52000838e3f R12: dffffc0000000000 R13: ffff888041f9e3c0 R14: ffff888086ee3802 R15: 0000000000000000 FS: 00007f6fe985d6c0(0000) GS:ffff888126176000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f80bd437dac CR3: 0000000025096000 CR4: 00000000003526f0 DR0: ffffffffffffffff DR1: 00000000000001f8 DR2: 0000000000000002 DR3: ffffffffefffff15 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Call Trace: <TASK> check_local_dest net/hsr/hsr_forward.c:592 [inline] fill_frame_info net/hsr/hsr_forward.c:728 [inline] hsr_forward_skb+0xa11/0x2a80 net/hsr/hsr_forward.c:739 hsr_dev_xmit+0x253/0x370 net/hsr/hsr_device.c:236 __netdev_start_xmit include/linux/netdevice.h:5368 [inline] netdev_start_xmit include/linux/netdevice.h:5377 [inline] xmit_one net/core/dev.c:3888 [inline] dev_hard_start_xmit+0x2df/0x860 net/core/dev.c:3904 __dev_queue_xmit+0x1428/0x3900 net/core/dev.c:4870 neigh_output include/net/neighbour.h:556 [inline] ip_finish_output2+0xcec/0x10b0 net/ipv4/ip_output.c:237 ip_send_skb net/ipv4/ip_output.c:1510 [inline] ip_push_pending_frames+0x8b/0x110 net/ipv4/ip_output.c:1530 raw_sendmsg+0x1547/0x1a50 net/ipv4/raw.c:659 sock_sendmsg_nosec net/socket.c:787 [inline] __sock_sendmsg net/socket.c:802 [inline] ____sys_sendmsg+0x7da/0x9c0 net/socket.c:2698 ___sys_sendmsg+0x2a5/0x360 net/socket.c:2752 __sys_sendmsg net/socket.c:2784 [inline] __do_sys_sendmsg net/socket.c:2789 [inline] __se_sys_sendmsg net/socket.c:2787 [inline] __x64_sys_sendmsg+0x1c3/0x2a0 net/socket.c:2787 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x15f/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f6feb62ce59 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f6fe985d028 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f6feb8a6090 RCX: 00007f6feb62ce59 RDX: 0000000000000000 RSI: 0000200000000000 RDI: 0000000000000004 RBP: 00007f6feb6c2d6f R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f6feb8a6128 R14: 00007f6feb8a6090 R15: 00007ffcf01cc488 </TASK>
In the Linux kernel, the following vulnerability has been resolved: signal: clear JOBCTL_PENDING_MASK for caller in zap_other_threads() When a multi-threaded process receives a stop signal (e.g., SIGSTOP), do_signal_stop() sets JOBCTL_STOP_PENDING and JOBCTL_STOP_CONSUME on all threads and sets signal->group_stop_count to the number of threads. If one of the threads concurrently calls execve(), de_thread() invokes zap_other_threads() to kill all other threads. zap_other_threads() aborts the pending group stop by resetting signal->group_stop_count to 0 and clears the JOBCTL_PENDING_MASK for all other threads. However, it fails to clear the job control flags for the calling thread. When execve() completes, the calling thread returns to user mode and checks for pending signals. Seeing the stale JOBCTL_STOP_PENDING flag, it calls do_signal_stop(), which invokes task_participate_group_stop(). Since JOBCTL_STOP_CONSUME is still set, it attempts to decrement the already-zero signal->group_stop_count, triggering a warning: sig->group_stop_count == 0 WARNING: CPU: 1 PID: 6475 at kernel/signal.c:373 task_participate_group_stop+0x215/0x2d0 Call Trace: <TASK> do_signal_stop+0x3be/0x5c0 kernel/signal.c:2619 get_signal+0xa8c/0x1330 kernel/signal.c:2884 arch_do_signal_or_restart+0xbc/0x840 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop+0x8c/0x4d0 kernel/entry/common.c:98 do_syscall_64+0x33e/0xf80 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> Fix this race condition by clearing the JOBCTL_PENDING_MASK for the calling thread in zap_other_threads(), ensuring it does not retain any stale job control state after the thread group is destroyed. This aligns with other functions that tear down a thread group and abort group stops, such as zap_process() and complete_signal(), which correctly clear these flags for all threads including the current one.
In the Linux kernel, the following vulnerability has been resolved: riscv/ptrace: Use USER_REGSET_NOTE_TYPE for REGSET_CFI Fixes a warning while dumping core: [54983.546369][ C7] WARNING: [!note_name] fs/binfmt_elf.c:1771 at elf_core_dump+0x910/0xf68, CPU#7: abort01/31982
In the Linux kernel, the following vulnerability has been resolved: ASoC: wm_adsp: Fix NULL dereference when removing firmware controls In wm_adsp_control_remove() check that the priv pointer is not NULL before attempting to cleanup what it points to. When cs_dsp creates a control it calls wm_adsp_control_add_cb() so that wm_adsp can create its own private control data. There are two cases where private data is not created: 1. The control is a SYSTEM control, so an ALSA control is not created. 2. The codec driver has registered a control_add() callback that hides the control, so wm_adsp_control_add() is not called. When cs_dsp_remove destroys its control list it calls wm_adsp_control_remove() for each control. But wm_adsp_control_remove() was attempting to cleanup the private data pointed to by cs_ctl->priv without checking the pointer for NULL.
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack: destroy stale expectfn expectations on unregister NAT helpers such as nf_nat_h323 store a raw pointer to module text in exp->expectfn (e.g. ip_nat_q931_expect). nf_ct_helper_expectfn_unregister() only unlinks the callback descriptor and never walks the expectation table, so an expectation pending at module removal survives with a dangling exp->expectfn into freed module text. When the expected connection arrives, init_conntrack() invokes exp->expectfn(), now a stale pointer into the unloaded module. Reproduced on a KASAN build by loading the H.323 helpers, creating a Q.931 expectation, unloading nf_nat_h323, then connecting to the expected port: Oops: int3: 0000 [#1] SMP KASAN NOPTI RIP: 0010:0xffffffffa06102d1 init_conntrack.isra.0 (net/netfilter/nf_conntrack_core.c:1862) nf_conntrack_in (net/netfilter/nf_conntrack_core.c:2049) ipv4_conntrack_local (net/netfilter/nf_conntrack_proto.c:223) nf_hook_slow (net/netfilter/core.c:619) __ip_local_out (net/ipv4/ip_output.c:120) __tcp_transmit_skb (net/ipv4/tcp_output.c:1715) tcp_connect (net/ipv4/tcp_output.c:4374) tcp_v4_connect (net/ipv4/tcp_ipv4.c:345) __sys_connect (net/socket.c:2167) Modules linked in: nf_conntrack_h323 [last unloaded: nf_nat_h323] Reaching the dangling state requires CAP_SYS_MODULE in the initial user namespace to remove a NAT helper that still has live expectations, so this is a robustness fix; leaving an expectation pointing at freed text is wrong regardless. Add nf_ct_helper_expectfn_destroy(), which walks the expectation table and drops every expectation whose ->expectfn matches the descriptor being torn down. Call it from each NAT helper's exit path after the existing RCU grace period, so no expectation outlives the code it points at and no extra synchronize_rcu() is introduced. With the fix, the same reproducer runs to completion without the Oops.
In the Linux kernel, the following vulnerability has been resolved: KVM: Don't WARN if memory is dirtied without a vCPU when the VM is dying When marking a page dirty, complain about not having a running/loaded vCPU if and only if the VM is still alive, i.e. its refcount is non-zero. This will allow fixing a memory leak for x86 SEV-ES guests without hitting what is effectively a false positive on the WARN. For some SEV-ES VM-Exits, KVM keeps a writable mapping of a guest page across an exit to userspace, and typically unmaps the page on the next KVM_RUN. But if userspace never calls KVM_RUN after such an exit, then KVM needs to unmap the page when the vCPU is destroyed, which in turn triggers the WARN about not having a running vCPU. Alternatively, SEV-ES could temporarily load the vCPU to suppress the WARN, as is done in nested_vmx_free_vcpu() (but for completely unrelated reasons; suppressing WARN from nested_put_vmcs12_pages() is pure happenstance). But loading a vCPU during destruction is gross (ideally nVMX code would be cleaned up), risks complicating the SEV-ES code (KVM would need to ensure the temporarily load()+put() only runs when the vCPU isn't already loaded), and is ultimately pointless. The motivation for the WARN is to guard against KVM dirtying guest memory without pushing the corresponding GFN to the active vCPU's dirty ring, e.g. to ensure userspace doesn't miss a dirty page. But for the VM's refcount to reach zero, there can't be _any_ userspace mappings to the dirty ring, as mapping the dirty ring requires doing mmap() on the vCPU FD. I.e. if userspace had a valid mapping for the dirty ring, then the vCPU file and thus the owning VM would still be alive. And so since userspace can't possibly reach the dirty ring, whether or not KVM technically "misses" a push to the dirty ring is irrelevant.
In the Linux kernel, the following vulnerability has been resolved: arm64: mm: call pagetable dtor when freeing hot-removed page tables Since 5e8eb9aeeda3 ("arm64: mm: always call PTE/PMD ctor in __create_pgd_mapping()") page-table allocation on ARM64 always calls pagetable_{pte,pmd,pud,p4d}_ctor(). This sets the page_type to PGTY_table, increments NR_PAGETABLE and possible allocates a PTL. However the matching pagetable_dtor() calls were never added. With DEBUG_VM enabled on kernel versions prior to v6.17 without 2dfcd1608f3a9 ("mm/page_alloc: let page freeing clear any set page type") this leads to the following warning when freeing these pages due to page->page_type sharing page->_mapcount: BUG: Bad page state in process ... pfn:284fbb page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x284fbb flags: 0x17fffc000000000(node=0|zone=2|lastcpupid=0x1ffff) page_type: f2(table) page dumped because: nonzero mapcount Call trace: bad_page+0x13c/0x160 __free_frozen_pages+0x6cc/0x860 ___free_pages+0xf4/0x180 free_pages+0x54/0x80 free_hotplug_page_range.part.0+0x58/0x90 free_empty_tables+0x438/0x500 __remove_pgd_mapping.constprop.0+0x60/0xa8 arch_remove_memory+0x48/0x80 try_remove_memory+0x158/0x1d8 offline_and_remove_memory+0x138/0x180 It can also lead to leaking the ptl allocation if ALLOC_SPLIT_PTLOCKS is defined and incorrect NR_PAGETABLE stats. Fix this by calling pagetable_dtor() in free_hotplug_pgtable_page() prior to freeing the page to undo the effects of calling pagetable_*_ctor().
In the Linux kernel, the following vulnerability has been resolved: nvmem: layouts: onie-tlv: fix hang on unknown types The EEPROM on my board has a vendor specific entry of type 0x41. When stumbling upon that, this driver hangs in an endless loop. Fix it by keep incrementing the offset on unknown entries, so the loop will eventually stop.
In the Linux kernel, the following vulnerability has been resolved: mm/mincore: handle non-swap entries before !CONFIG_SWAP guard mincore_swap() also fields migration/hwpoison entries (and shmem swapin-error entries), which can exist on !CONFIG_SWAP builds when CONFIG_MIGRATION or CONFIG_MEMORY_FAILURE is enabled. The !IS_ENABLED(CONFIG_SWAP) guard ran before the non-swap-entry early return, so mincore_pte_range() can spuriously WARN and report these pages nonresident on !CONFIG_SWAP kernels. Move the guard below the non-swap-entry check so only true swap entries trip the WARN, and migration/hwpoison entries take the existing "uptodate / non-shmem" path.
In the Linux kernel, the following vulnerability has been resolved: slimbus: qcom-ngd-ctrl: Register callbacks after creating the ngd When the remoteproc starts in parallel with the NGD driver being probed, or the remoteproc is already up when the PDR lookup is being registered, or in the theoretical event that we get an interrupt from the hardware, these callbacks will operate on uninitialized data. This result in issues to boot the affected boards. One such example can be seen in the following fault, where qcom_slim_ngd_ssr_pdr_notify() schedules work on the NULL ngd_up_work. [ 21.858578] ------------[ cut here ]------------ [ 21.858745] WARNING: kernel/workqueue.c:2338 at __queue_work+0x5e0/0x790, CPU#2: kworker/2:2/116 ... [ 21.859251] Call trace: [ 21.859255] __queue_work+0x5e0/0x790 (P) [ 21.859265] queue_work_on+0x6c/0xf0 [ 21.859273] qcom_slim_ngd_ssr_pdr_notify+0x110/0x150 [slim_qcom_ngd_ctrl] [ 21.859304] qcom_slim_ngd_ssr_notify+0x24/0x40 [slim_qcom_ngd_ctrl] [ 21.859318] notifier_call_chain+0xa4/0x230 [ 21.859329] srcu_notifier_call_chain+0x64/0xb8 [ 21.859338] ssr_notify_start+0x40/0x78 [qcom_common] [ 21.859355] rproc_start+0x130/0x230 [ 21.859367] rproc_boot+0x3d4/0x518 ... Move the enablement of interrupts, and the registration of SSR and PDR until after the NGD device has been registered. This could be further refined by moving initialization to the control driver probe and by removing the platform driver model from the picture.
In the Linux kernel, the following vulnerability has been resolved: slimbus: qcom-ngd-ctrl: Avoid ABBA on tx_lock/ctrl->lock During the SSR/PDR down notification the tx_lock is taken with the intent to provide synchronization with active DMA transfers. But during this period qcom_slim_ngd_down() is invoked, which ends up in slim_report_absent(), which takes the slim_controller lock. In multiple other codepaths these two locks are taken in the opposite order (i.e. slim_controller then tx_lock). The result is a lockdep splat, and a possible deadlock: rprocctl/449 is trying to acquire lock: ffff00009793e620 (&ctrl->lock){+.+.}-{4:4}, at: slim_report_absent (drivers/slimbus/core.c:322) slimbus but task is already holding lock: ffff00009793fb50 (&ctrl->tx_lock){+.+.}-{4:4}, at: qcom_slim_ngd_ssr_pdr_notify (drivers/slimbus/qcom-ngd-ctrl.c:1475) slim_qcom_ngd_ctrl which lock already depends on the new lock. Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&ctrl->tx_lock); lock(&ctrl->lock); lock(&ctrl->tx_lock); lock(&ctrl->lock); The assumption is that the comment refers to the desire to not call qcom_slim_ngd_exit_dma() while we have an ongoing DMA TX transaction. But any such transaction is initiated and completed within a single qcom_slim_ngd_xfer_msg(). Prior to calling qcom_slim_ngd_exit_dma() the slim_controller is torn down, all child devices are notified that the slimbus is gone and the child devices are removed. Stop taking the tx_lock in qcom_slim_ngd_ssr_pdr_notify() to avoid the deadlock.
In the Linux kernel, the following vulnerability has been resolved: sched_ext: Don't warn on NULL cgrp_moving_from in scx_cgroup_move_task() A WARN fires when systemd's user manager writes "+cpu +memory +pids" to its own subtree_control while a sched_ext scheduler is loaded: WARNING: at kernel/sched/ext.c:3227 scx_cgroup_move_task+0xa8/0xb0 scx_cgroup_move_task+0xa8/0xb0 sched_move_task+0x134/0x290 cpu_cgroup_attach+0x39/0x70 cgroup_migrate_execute+0x37d/0x450 cgroup_update_dfl_csses+0x1e3/0x270 cgroup_subtree_control_write+0x3e7/0x440 scx_cgroup_can_attach() arms cgrp_moving_from only when a task's cpu cgroup changes. It can still be NULL when scx_cgroup_move_task() runs, through this sequence: Step Result --------------------------------- ---------------------------------- 1. cpu enabled on cgroup G cpu css = A 2. cpu toggled off then on for G A killed, B created (same cgroup) 3. an exiting task keeps A alive migration skips it, A now stale 4. +memory migrates G stale A vs current B pulls cpu in 5. cpu attach runs for all tasks hits a live, cpu-unchanged task 6. scx_cgroup_move_task() on it cgrp_moving_from NULL -> WARN The mismatch is that scx_cgroup_can_attach() keys on cgroup identity while migration drives the move on css identity, so a NULL cgrp_moving_from here is a legitimate css-only migration, not a missing prep. The call is already gated on cgrp_moving_from, so just drop the warning. ops.cgroup_prep_move() and ops.cgroup_move() stay paired.
In the Linux kernel, the following vulnerability has been resolved: debugobjects: Do not fill_pool() if pi_blocked_on On RT enabled kernels, fill_pool() ends up calling rtlock_lock(), which asserts if current::pi_blocked_on is set, because a task can obviously only block on one lock as otherwise the priority inheritenace chain gets corrupted. Prevent this by expanding the conditional to take current::pi_blocked_on into account.
In the Linux kernel, the following vulnerability has been resolved: debugobjects: Don't call fill_pool() in early boot hardirq context When booting a debug PREEMPT_RT kernel on an ARM64 system, a "inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage" lockdep warning message was reported to the console. During early boot, interrupts are enabled before the scheduler is enabled. In this window (before SYSTEM_SCHEDULING is set) interrupts can fire and in the hard interrupt context handler attempt to fill the pool This can lead to a deadlock when the interrupt occurred when the interrupt hits a region which holds a lock that is required to be taken in the allocation path. Add a new can_fill_pool() helper and reorder the exception rule and forbid this scenario by excluding allocations from hard interrupt context.
Server-side URL manipulation in the pretix-oppwa payment plugin (fixed in pretix 2026.5.3) lets a remote attacker exfiltrate the Oppwa API access token by tampering with the resourcePath return parameter. Because the plugin concatenated the attacker-controlled resourcePath onto the API base domain without a separating slash or validation, a crafted value redirects pretix's server-side status-check request - which carries the account API key - to an attacker-controlled host. No public exploit identified at time of analysis, and the CVSS 4.0 vector carries E:U (exploit unproven).
User enumeration in MyComplianceOffice (MCO) version 25.3.3.1 allows unauthenticated remote attackers to identify valid usernames and email addresses by observing distinguishable application responses from the password reset and username reminder endpoints. The CWE-204 Observable Response Discrepancy root cause means account existence is leaked through differential error messages, status codes, or redirect behavior - classic reconnaissance fodder for follow-on credential stuffing or targeted phishing against compliance personnel. No public exploit code has been identified and no CISA KEV listing exists; however, vendor contact was unsuccessful, leaving patch status unresolved and version scope uncertain beyond the confirmed 25.3.3.1 release.
Unauthorized private content disclosure in the Slim SEO WordPress plugin (all versions through 4.9.8) allows authenticated Contributors to read protected content they do not own via the `/wp-json/slim-seo/meta-tags/ai` REST API endpoint. The endpoint's broken object-level authorization - checking only the generic `edit_posts` capability rather than per-post read access - lets any Contributor supply an arbitrary post ID and receive an AI-generated summary of that post's raw content, including private, draft, pending, future, and password-protected posts authored by other users. No public exploit or CISA KEV listing is identified at time of analysis; real-world risk is constrained by the requirement for a pre-existing Contributor-level account.
Weak password hash storage in BMC Control-M/Enterprise Manager exposes account credentials to offline recovery attacks if an attacker gains access to the credential database. Affected are unsupported versions 9.0.20.x and potentially earlier legacy releases, meaning no vendor patch will be issued for these branches - upgrade to a supported release is the only vendor-endorsed remediation. The CVSS 4.0 vector (AV:L/PR:H/AT:P) confirms exploitation requires local, high-privilege access and specific attack conditions, significantly constraining real-world risk; no public exploit code and no CISA KEV listing have been identified at time of analysis.
Denial-of-service exposure in the Delta Electronics DVP80ES3 programmable logic controller (part of the DVP-ES3 series) stems from an improperly implemented standard security check (CWE-358) that a remote, unauthenticated attacker can abuse over the network to force a loss of availability. The CVSS 4.0 base score is 8.7 (High), driven entirely by high availability impact with no confidentiality or integrity impact in the scored vector. There is no public exploit identified at time of analysis and it is not listed in CISA KEV; note that the vendor's tags label this 'Information Disclosure,' which conflicts with the availability-only CVSS vector and should be verified against the Delta advisory.
Denial of service in Delta Electronics DVP80ES3 programmable logic controllers arises from a failure to enforce message integrity on a communication channel (CWE-924), allowing remote, unauthenticated attackers to inject or tamper with protocol messages and disrupt device availability. Per the vendor CVSS vector (AV:N/AC:L/PR:N/UI:N/C:N/I:N/A:H), the confirmed impact is loss of availability of this industrial controller with no privileges or user interaction required. There is no public exploit identified at time of analysis and it is not listed in CISA KEV, though the network-reachable, no-auth profile of an ICS device makes it operationally significant.
Denial of service in Delta Electronics DVP80ES3 programmable logic controllers arises from an improper resource shutdown or release flaw (CWE-404) that lets remote unauthenticated attackers exhaust or corrupt device resources. Per the CVSS vector the impact is limited to availability (A:H) with no confidentiality or integrity loss, meaning a successful attacker can crash or hang the PLC and disrupt the controlled industrial process. No public exploit identified at time of analysis; the issue is documented in Delta advisory Delta-PCSA-2026-00009, which bundles it with CVE-2026-12576 and CVE-2026-12577.
Subscription cancellation authorization bypass in the Fluent Forms WordPress plugin (all versions before 6.2.1) permits any authenticated low-privilege user to cancel subscriptions belonging to other site members by submitting a crafted request referencing a victim's subscription identifier. The plugin fails to verify that the requesting user owns the referenced subscription before processing the cancellation, a classic Insecure Direct Object Reference (IDOR) pattern. A public proof-of-concept is available via WPScan; no confirmed active exploitation campaign (CISA KEV) has been identified at time of analysis, and the CVSS base score of 3.1 reflects the limited, integrity-only impact.
Privilege escalation in the Advanced Form Integration - Connect Forms to 200+ Apps WordPress plugin before 2.1.1 allows unauthenticated visitors to provision a full administrator account through a public form. Because the plugin fails to restrict which WordPress role it assigns during user creation, any site that maps the user-role field to a public form input via an active integration exposes site takeover to anonymous submitters. Publicly available exploit code exists (reported by WPScan), though this is not listed in CISA KEV and requires a specific non-default integration configuration, so real-world exposure is narrower than the 8.1 CVSS suggests.
Missing capability check in WS Form LITE WordPress plugin before 1.11.8 allows any authenticated subscriber-level WordPress user to modify the plugin's settings, an action that should be restricted to administrators. The CVSS vector (PR:L) confirms low-privilege authentication is sufficient, and a publicly available proof-of-concept has been documented by WPScan. No active exploitation has been confirmed by CISA KEV, but the low barrier to exploitation and available POC make this a credible risk on multi-user WordPress installations where untrusted subscribers exist.
Broken access control in the Royal MCP WordPress plugin before 1.4.26 lets any authenticated low-privileged user (e.g. Subscriber) invoke privileged MCP tools that skip capability checks after token authentication, exposing private content, full user/role enumeration, and create/modify/delete operations on other users' content. Reported by WPScan with a publicly available exploit and a vendor patch in 1.4.26; the CVSS 8.1 vector (PR:L) confirms authenticated but not administrative access is required. There is no public exploit identified as actively exploited - status is POC only, not CISA KEV.
Denial-of-service in the Delta Electronics DVP80ES300T programmable logic controller allows remote unauthenticated attackers to crash the device by triggering an improper array-index validation flaw (CWE-129). Per the CVSS vector the impact is limited to availability (A:H) with no confidentiality or integrity loss, so a successful attack halts PLC operation rather than exposing data. There is no public exploit identified at time of analysis and it is not listed in CISA KEV; EPSS was not provided.
Sensitive PII exposure in the Appointment Booking Calendar WordPress plugin (versions up to and including 1.4.02) allows any authenticated user with contributor-level access to retrieve customer booking records - including names, email addresses, phone numbers, and appointment comments - via the unprotected `cpabc_appointments_filter_list` AJAX action. The root cause is CWE-862 (Missing Authorization): the endpoint performs no capability check before returning data, meaning the attacker's only prerequisite is a valid WordPress login at contributor tier or above. No public exploit code or active exploitation (CISA KEV) has been identified at time of analysis, but a source-level fix appears committed in the plugin's SVN repository (changeset 3581633).
Arbitrary zero-argument PHP function invocation in the Youtube Showcase (Video Gallery - YouTube Gallery, Playlist & Video Grid) plugin for WordPress affects all versions up to and including 4.0.3, letting authenticated Subscriber-level users abuse the emd_delete_file() AJAX handler to call any callable PHP function name with no arguments. Because the handler validates only a nonce and omits a current_user_can() capability check, low-privileged accounts can trigger functions such as phpinfo(), get_defined_vars(), or error_get_last() to disclose sensitive server and application data. No public exploit identified at time of analysis and the issue is not in CISA KEV, so risk is currently theoretical but credible given the low privilege bar.
Credential disclosure in UltraVNC through 1.8.2.2 lets a passive network observer break the MS-Logon II authentication handshake and recover plaintext usernames and passwords. The rfbUltraVNC_MsLogonIIAuth scheme relies on a Diffie-Hellman exchange whose prime fits in an unsigned 64-bit integer and a private exponent derived from time(NULL)-seeded libc rand(), both of which are trivially solvable, so an attacker who sniffs or man-in-the-middles the exchange derives the shared key in seconds to a minute. There is no public exploit identified at time of analysis and no EPSS/KEV signal supplied; CVSS is 7.4 (AC:H reflecting the need to observe the handshake), and MS-Logon III (X25519 + AES-256-GCM) is not affected.
UltraVNC through 1.8.2.2 exposes a cryptographically weak VNC authentication challenge generator that an attacker can predict by observing network traffic and enumerating a roughly 31-bit seed space derived from wall-clock time and process ID. Successful seed reconstruction allows the attacker to forge or brute-force valid VNC authentication responses, effectively bypassing the RFB challenge-response mechanism and gaining unauthorized remote desktop access. No public exploit has been identified at time of analysis, and the vulnerability is not currently listed in the CISA KEV catalog; however, the mathematical basis for exploitation is straightforward given the small seed space.
Out-of-bounds read in UltraVNC through version 1.8.2.2 allows network-authenticated attackers to potentially crash the VNC server process or leak adjacent memory content via the vncWc2Mb() wide-string conversion helper in rfb/dh.cpp at line 204. The flaw is triggered when wcslen() is called on a caller-supplied WCHAR pointer without a preceding bounds check, enabling memory over-reads if the buffer lacks proper NUL termination. No public exploit code or active exploitation has been identified at time of analysis; the vendor's CVSS 4.3 (Medium) rating reflects the constrained and largely denial-of-service-oriented impact.
Information disclosure in MediaTek modem firmware across 67+ chipset models enables a network-adjacent attacker operating a rogue cellular base station to extract sensitive data from a victim's User Equipment (UE) without any privileges or user interaction. The root cause is improper input validation (CWE-288) in the modem baseband stack, allowing a fake cell tower to elicit confidential data from connected devices. No active exploitation has been confirmed by CISA KEV, and SSVC assessment rates exploitation as 'none' at time of analysis, though the architecture of the attack closely resembles IMSI-catcher and stingray-type tradecraft used in targeted surveillance operations.
CVE-2026-45383 has no publicly available description, CVSS score, CWE classification, or technical details at time of analysis. The sole intelligence signal is a report attribution to the Ubuntu vendor source, suggesting this may affect a package within the Ubuntu ecosystem. No impact, attack vector, or affected version data can be synthesized without a description - any characterization beyond this would be fabricated.
CVE-2026-45382 is associated with Ubuntu Linux based on the sole reporting source (vendor:ubuntu), but no description, CVSS score, CWE classification, or affected version data was provided in the intelligence feed. The vulnerability's nature, impact, and exploitability are entirely unknown from available data. No assessment of attacker capability or affected user population is possible without a vendor advisory or NVD entry.
Insufficient data exists to characterize CVE-2026-54240 with confidence. The sole intelligence source is a vendor report attributed to Ubuntu, but no description, CVSS score, CWE classification, CPE strings, or references were provided. The affected component, vulnerability class, and impact cannot be determined from available data. No exploitation status, patch availability, or EPSS signal is present.
CVE-2026-54241 is reported by the Ubuntu vendor source with no description, CVSS score, CWE classification, or supplementary intelligence available at time of analysis. The affected product or component within the Ubuntu ecosystem cannot be determined from the provided data. No exploitation status, patch details, or technical context can be assessed.
UI spoofing in Google Chrome's DevTools component allows an attacker to misrepresent critical interface information to users who have been socially engineered into installing a malicious Chrome Extension. Affected versions are all Chrome releases prior to 150.0.7871.47. The flaw stems from an inappropriate implementation (CWE-451) in DevTools, enabling an extension to manipulate how DevTools renders UI elements - potentially deceiving developers or power users into trusting falsified debugging output or security indicators. No public exploit code has been identified at time of analysis, and this vulnerability is not in the CISA KEV catalog.
UI spoofing in the Glic component of Google Chrome (all versions prior to 150.0.7871.47) enables a remote attacker to misrepresent browser interface elements via a crafted HTML page, provided the victim is socially engineered into performing specific UI gestures. The CVSS vector (AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:N/A:N) assigns high confidentiality impact, suggesting the spoofed UI can be leveraged to elicit disclosure of sensitive information such as credentials or session data. No public exploit code exists and this vulnerability is not listed in the CISA KEV catalog at time of analysis.
Sandbox escape in Google Chrome desktop before 150.0.7871.47 lets an attacker who has already compromised the renderer process break out of the security sandbox using a crafted HTML page, elevating from a contained renderer to broader host access. Rooted in CWE-669 (incorrect resource transfer between spheres) within Chrome's AI component, it carries a CVSS 8.3 (scope-changed) rating despite Google's own 'Low' Chromium severity, reflecting the fact that it is a second-stage escape rather than a standalone entry point. There is no public exploit identified at time of analysis, EPSS exploitation probability is low (0.17%, 7th percentile), and it is not listed in CISA KEV.
UI spoofing via the Speech component in Google Chrome prior to 150.0.7871.47 requires an attacker to have already compromised the renderer process, making this a chained, second-stage exploit rather than a standalone remote attack. The vulnerability stems from insufficient input validation (CWE-20) in Chrome's Speech subsystem, enabling a renderer-compromised attacker to manipulate browser UI elements through a crafted HTML page. No public exploit code exists, SSVC assessment confirms no active exploitation, and an EPSS score of 0.17% (7th percentile) reflects a very low probability of mass exploitation - consistent with Google's own 'Low' internal severity rating.
Type confusion in the CSS processing engine of Google Chrome prior to 150.0.7871.47 enables remote attackers to read potentially sensitive data from renderer process memory by delivering a crafted HTML page to a victim. The CVSS vector (AV:N/AC:L/PR:N/UI:R) confirms network delivery with no attacker privileges required, though a single user interaction - visiting the malicious page - is necessary. No public exploit code has been identified, CISA SSVC rates exploitation as none at time of analysis, and Chromium's own team classified severity as Low, suggesting limited practical memory disclosure value despite the NVD CVSS C:H rating.
Cross-origin data leak in Google Chrome's CSS implementation (versions prior to 150.0.7871.47) enables remote attackers to exfiltrate sensitive data from other origins when a victim visits a specially crafted HTML page. The vulnerability stems from inappropriate CSS handling that creates a side-channel bypassing same-origin policy protections, resulting in high-confidentiality-impact information disclosure with no integrity or availability consequences. No public exploit has been identified and exploitation has not been observed in the wild; CISA SSVC rates exploitation as none and technical impact as partial, aligning with Google's internal Low severity classification despite the NVD CVSS 6.5 score.