| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Mitigation bypass in the Enterprise Policies component. This vulnerability was fixed in Firefox 158, Firefox ESR 153.5, Thunderbird 158, and Thunderbird 153.5. |
| Mitigation bypass in the DOM: Security component. This vulnerability was fixed in Firefox 158 and Thunderbird 158. |
| destructive_command_guard (dcg) is a command-line safety tool that blocks destructive shell commands before AI coding agents run them. Prior to 0.6.6, nested or unclosed substitutions are recursively rescanned after an inner scan returns unterminated, producing exponential-time work. The affected scanners are reached through split_command_segments in src/packs/mod.rs. a destructive command followed by nested or unclosed $( or $(( sequences. nested or unclosed $( and $(( sequences cause repeated rescanning of the remaining command suffix. a hung PreToolUse hook fails open, allowing the destructive command to proceed. This issue is fixed in version 0.6.6. |
| Mitigation bypass in the Networking: HTTP component. This vulnerability was fixed in Firefox 158, Firefox ESR 153.5, Thunderbird 158, and Thunderbird 153.5. |
| Mitigation bypass in the DOM: Security component. This vulnerability was fixed in Firefox 158, Firefox ESR 153.5, Thunderbird 158, and Thunderbird 153.5. |
| In the Linux kernel, the following vulnerability has been resolved:
tpm: Disable TPM on null key name mismatch
The null key name check exists to protect against TPM reset attacks, so
a mismatch should stop the device from serving further requests.
Currently it does not disable the chip when it finds a mismatch.
The mismatch is logged:
tpm tpm0: null key integrity check failed
but the chip keeps serving commands:
/ # tpm2_getcap -c properties-fixed
TPM_PT_FAMILY_INDICATOR:
as UINT32: 0x08322e3000
as string: "2.0"
...
tpm2_load_null() where the null key name check is run sets the chip as
disabled only if the rc is non zero. When the mismatch is seen, rc is
zero at that point and it returns success. The other issue is that the
caller expects the null key handle to be populated when the function
returns 0 which it does here without writing the handle and proceeds
assuming the null key handle is valid.
During the test, I noticed that tpm2_start_auth_session() uses the
uninitialized stack value as the key handle since tpm2_load_null()
returns 0 despite the integrity failure and proceeds with
TPM2_CC_START_AUTH_SESS with this value as salt key handle.
Set rc to -ENODEV on the mismatch. The error path then disables the chip
and returns the correct code to the caller.
Tested in QEMU with swtpm and CONFIG_TCG_TPM2_HMAC=y by making
TPM2_CC_CONTEXT_LOAD fail with TPM2_RC_INTEGRITY and changing the name
of the re-created null key. The chip is now disabled on the mismatch. |
| Gitea's OpenID connect handler accepts a user's password without enforcing enrolled TOTP or WebAuthn verification before completing sign-in and linking an OpenID identifier. When OpenID sign-in is enabled, an attacker who knows the victim's password can obtain a session and link an attacker-controlled identifier. The attacker can then sign in through that identifier without the victim's password or second factor, and a password change does not remove the link. |
| For pull request events, Gitea reads workflow definitions from the pull request head and posts a synthetic skipped status when workflow branch or path filters exclude execution. A fork pull request author can supply a workflow matching a required status context but deliberately prevent it from running. Because skipped statuses count as success, branch protection or organization-required workflow checks can appear satisfied without the mandated workflow executing; no runner or maintainer approval is required for this path. |
| Sandbox escape in the DOM: Content Processes component. This vulnerability was fixed in Firefox 158 and Thunderbird 158. |
| ZoneMinder is a free, open source closed-circuit television software application. In versions 1.34.0 through 1.36.38, the web interface mishandles failed token authentication in web/includes/auth.php. validateToken() returns false when a token is malformed or has an invalid signature, but the caller assigns that value to the global $user variable; because web/index.php tests isset($user), boolean false is treated as a present user and the normal login redirect is skipped. This can dispatch views that rely on the outer authentication gate, including the zones view, which accepts an attacker-selected monitor ID and discloses monitor and zone metadata without an independent permission check. Permission helpers receive the false user value and deny privileged operations, so unauthorized state changes have not been established. This vulnerability is fixed in version 1.36.63, where conversion to ZM\User objects causes invalid token state to fail before view dispatch. Later defense-in-depth changes explicitly leave $user unset after failed token validation and reject non-ZM\User values at the web authentication gate. |
| Heym builds and runs agentic systems and business-process automations on self-hosted infrastructure. Prior to 0.0.40, an authenticated user who can create or edit a workflow with an Agent custom Python tool can bypass the blacklist-based sandbox in backend/app/services/python_tool_executor.py because allowed standard-library modules expose operating-system, process, and filesystem capabilities through public attributes that pass _safe_import() and _validate_code_safety(). The runner then executes the supplied tool with exec(), permitting commands and file operations as the backend application user; self-registration affects reachability, but portal triggering alone does not grant code control. This issue is fixed in 0.0.40. |
| Forms using FileUpload or ImageUpload elements with a custom saveToFileMount configured stored uploaded files in the default storage folder 1:/user_upload/ instead of the configured destination. This could cause uploaded files to end up in a publicly accessible storage even though a restricted, non-public storage had been configured. Files stored this way are served directly, without the access checks applied to non-public storages. Forms that use the default value for saveToFileMount are not affected. This issue affects TYPO3 CMS versions 14.0.0-14.3.8. |
| In the Linux kernel, the following vulnerability has been resolved:
net: skbuff: propagate shared-frag marker through frag-transfer helpers
Two frag-transfer helpers (__pskb_copy_fclone() and skb_shift()) fail
to propagate the SKBFL_SHARED_FRAG bit in skb_shinfo()->flags when
moving frags from source to destination. __pskb_copy_fclone() defers
the rest of the shinfo metadata to skb_copy_header() after copying
frag descriptors, but that helper only carries over gso_{size,segs,
type} and never touches skb_shinfo()->flags; skb_shift() moves frag
descriptors directly and leaves flags untouched. As a result, the
destination skb keeps a reference to the same externally-owned or
page-cache-backed pages while reporting skb_has_shared_frag() as
false.
The mismatch is harmful in any in-place writer that uses
skb_has_shared_frag() to decide whether shared pages must be detoured
through skb_cow_data(). ESP input is one such writer (esp4.c,
esp6.c), and a single nft 'dup to <local>' rule -- or any other
nf_dup_ipv4() / xt_TEE caller -- is enough to land a pskb_copy()'d
skb in esp_input() with the marker stripped, letting an unprivileged
user write into the page cache of a root-owned read-only file via
authencesn-ESN stray writes.
Set SKBFL_SHARED_FRAG on the destination whenever frag descriptors
were actually moved from the source. skb_copy() and skb_copy_expand()
share skb_copy_header() too but linearize all paged data into freshly
allocated head storage and emerge with nr_frags == 0, so
skb_has_shared_frag() returns false on its own; they need no change.
The same omission exists in skb_gro_receive() and skb_gro_receive_list().
The former moves the incoming skb's frag descriptors into the
accumulator's last sub-skb via two paths (a direct frag-move loop and
the head_frag + memcpy path); the latter chains the incoming skb whole
onto p's frag_list. Downstream skb_segment() reads only
skb_shinfo(p)->flags, and skb_segment_list() reuses each sub-skb's
shinfo as the nskb -- both p and lp must carry the marker.
The same omission also exists in tcp_clone_payload(), which builds an
MTU probe skb by moving frag descriptors from skbs on sk_write_queue
into a freshly allocated nskb. The helper falls into the same family
and warrants the same fix for consistency; no TCP TX-side in-place
writer is currently known to reach a user page through this gap, but
a future consumer depending on the marker would regress silently.
The same omission exists in skb_segment(): the per-iteration flag
merge takes only head_skb's flag, and the inner switch that rebinds
frag_skb to list_skb on head_skb-frags exhaustion does not fold the
new frag_skb's flag into nskb. Fold frag_skb's flag at both sites
so segments drawing frags from frag_list members carry the marker. |
| A flaw was found in BusyBox's mount utility. A non-root user can bypass mount security restrictions set in /etc/fstab by specifying clearing-mask options on the command line. These options pass the non-root flag filter and are merged with fstab options as strings; when the combined options are re-parsed, clearing options can override nosuid, nodev, and noexec protections the administrator intended to enforce. |
| Protection Mechanism Failure vulnerability in hexpm hex allows the owner of a package, or an attacker who has taken over the owner's account, to get a newly published release past the release-age cooldown.
The cooldown (cooldown config, HEX_COOLDOWN) withholds versions younger than the configured age during dependency resolution. When the release of a package locked in mix.lock is retired or has a security advisory, Hex.RemoteConverger.build_cooldown_bypass/3 and Hex.RemoteConverger.unsafe_lock_bypass/1 lift the cooldown for every version of that package and of every package the locked release depends on, so that mix deps.update can move off the unsafe release. Retiring a release needs the same package owner permission as publishing one. An attacker who publishes a malicious release can retire the currently locked release, and the next mix deps.update that unlocks the package selects the new release regardless of its age. Hex.Registry.Cooldown.versions/2 checks the bypass by package name alone, so the bypass also covers packages with the same name in other repositories. Cooldown configured through an organization dependency policy is not affected.
This issue affects hex: from 2.5.0 before 2.5.2. |
| As part of Cisco's ongoing commitment to proactive security and product quality, Cisco has conducted a comprehensive internal security review. This review resulted in a software hardening release that addresses multiple internally discovered vulnerabilities. The vulnerabilities tracked by CVE-2026-76283 are related to protection mechanism failure and are grouped under the Common Weakness Enumeration (CWE) CWE-693. |
| Protection mechanism failure for some Intel(R) AI Reference Models before version v3.4.1 within Ring 3: User Applications may allow an escalation of privilege. Unprivileged software adversary with a privileged user combined with a low complexity attack may enable escalation of privilege. This result may potentially occur via local access when attack requirements are present without special internal knowledge and requires passive user interaction. The potential vulnerability may impact the confidentiality (high), integrity (high) and availability (high) of the vulnerable system, resulting in subsequent system confidentiality (none), integrity (none) and availability (none) impacts. |
| OTRS does not sufficiently enforce the uniqueness of customer user identities across multiple configured CustomerUser backends. When multiple backends, such as a database and LDAP, are configured, the uniqueness check for customer user email addresses is performed only within the selected backend. As a result, an authenticated user with permission to create or modify customer users may create a customer user whose email address is already assigned to a customer user in another backend.
This can result in multiple customer user records representing the same communication identity. Depending on the affected workflow and backend resolution, customer-related information or email communication may subsequently be associated with or exposed to the wrong customer user.
The vulnerability does not allow unauthenticated users to create customer accounts. Exploitation requires permissions to create or modify customer users.
This issue affects OTRS:
* 7.0.X
* 8.0.X
* 2023.X
* 2024.X
* 2025.X
* 2026.X before 2026.7.X
Please note that ((OTRS)) Community Edition 6.x and before are vulnerable. Products based on the ((OTRS)) Community Edition also very likely to be affected |
| OWASP Coraza WAF is a golang modsecurity compatible web application firewall library. From 3.0.0 until 3.8.1, Coraza silently drops arguments after SecArgumentsLimit in internal/corazawaf/transaction.go, while internal/bodyprocessors/urlencoded.go writes ARGS_POST without enforcing the cap. The flaw is triggered when an unauthenticated attacker sends more arguments than SecArgumentsLimit or supplies bodies that expand beyond the configured argument and flattening budgets. An unauthenticated attacker can flood requests with arguments so excess values are silently omitted from ARGS, ARGS_GET, ARGS_NAMES, ARGS_GET_NAMES, ARGS_POST, or ARGS_PATH before security rules inspect them; affected urlencoded and JSON processing can also consume excessive memory. The omission can bypass WAF rules protecting the downstream application, and unbounded or amplified argument processing can cause memory consumption and service degradation. This issue is fixed in version 3.8.1. |
| Path Traversal (CWE-22) in the execute_obj function of the archive object viewer (peach.pas) in PeaZip 11.2.0 and earlier on Windows allows an attacker who convinces a victim to preview an entry of a crafted archive via the "Preview with... -> Associated application" action (Shift+Ctrl+O) to execute an arbitrary program already present on the victim's system, with no warning dialog. The function validates only outname (PeaZip's own temporary directory) with checkfiledirname, while the string actually executed is the concatenation outname+tempstring; tempstring is taken verbatim from the archive entry name (StringGridList.Cells[12,...]) and is never validated. checkfiledirname (list_utils.pas) rejects control and reserved characters in the file name but performs no ".." path-containment check, so an entry named ../../../../Windows/System32/calc.exe escapes the extraction directory and is passed to cp_open -> ShellExecuteW; the extracting backend (7-Zip) strips the traversal while the opener does not. In addition, the SECEXTCONST dangerous-extension confirmation prompt is implemented only in the double-click handler (grid_obj_open) and not on this preview route, so an executable inside an archive reaches ShellExecuteW unannounced, and where the prompt does fire it names the entry's display name rather than the resolved path that will run. Arbitrary code execution was demonstrated with a proof of concept against official PeaZip builds, confirmed on two archive formats (.zip and .tar) to show the defect is in PeaZip's own path handling and not in a single format parser. |
