| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
f2fs: validate compress cache inode only when enabled
F2FS_COMPRESS_INO() uses NM_I(sbi)->max_nid as the synthetic inode
number for the compressed page cache inode. That inode only exists when
the compress_cache mount option is enabled.
When compress_cache is disabled, max_nid is outside the valid inode
range. A corrupted directory entry that points to ino == max_nid should
therefore be rejected by f2fs_check_nid_range(). However, is_meta_ino()
currently treats F2FS_COMPRESS_INO() as a meta inode unconditionally,
so f2fs_iget() bypasses do_read_inode() and its nid range check, and
instantiates a fake internal inode instead.
Gate the compressed cache inode case on COMPRESS_CACHE, matching
f2fs_init_compress_inode(). With compress_cache disabled, ino ==
max_nid now follows the normal inode path and is rejected as an
out-of-range nid. |
| In the Linux kernel, the following vulnerability has been resolved:
netfilter: conntrack: tcp: do not force CLOSE on invalid-seq RST without direction check
An unintended behavior in the TCP conntrack state machine allows a
connection to be forced into the CLOSE state using an RST packet with an
invalid sequence number.
Specifically, after a SYN packet is observed, an RST with an invalid SEQ
can transition the conntrack entry to TCP_CONNTRACK_CLOSE, regardless of
whether the RST corresponds to the expected reply direction. The relevant
code path assumes the RST is a response to an outgoing SYN, but does not
validate packet direction or ensure that a matching SYN was actually sent
in the opposite direction.
As a result, a crafted packet sequence consisting of a SYN followed by an
invalid-sequence RST can prematurely terminate an active NAT entry. This
makes connection teardown easier than intended.
So, tighten the state transition logic to ensure that RST-triggered
CLOSE transitions only occur when the RST is a valid response to a
previously observed SYN in the correct direction. |
| Puma is a Ruby/Rack web server built for parallelism. From 5.5.0 until 7.2.1 and 8.0.2, Puma is vulnerable to source IP spoofing when set_remote_address proxy_protocol: :v1 is enabled and persistent connections are used because Puma incorrectly re-parses PROXY protocol headers after each keep-alive request on the same connection, allowing an attacker to inject a second PROXY header and overwrite REMOTE_ADDR. This issue is fixed in versions 7.2.1 and 8.0.2. |
| Improperly implemented security check for standard in Windows Secure Boot allows an authorized attacker to bypass a security feature locally. |
| In sshd in OpenSSH before 10.4, DisableForwarding=yes was supposed to take precedence over PermitTunnel=yes, but did not. |
| In liboauth2 the Demonstrating Proof-of-Possession (DPoP) verifier accepts a proof whose JSON Web Key (jwk) header contains private key material. RFC 9449 section 4.3 step 7 requires the verifier to reject such a proof but oauth2_token_verify() function returns success for a malformed DPoP proof that embeds the private Elliptic Curve (EC) key in the header.
This issue was fixed in version 2.3.0 |
| DVP80ES3 with Improperly Implemented Security Check for Standard vulnerability. |
| Always-Incorrect Control Flow Implementation vulnerability in Apache Tomcat's rewrite valve meant that if the first condition in an OR chain matched, subsequent non-OR conditions were skipped.
This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.22, from 10.1.0-M1 through 10.1.55, from 9.0.0.M1 through 9.0.118, from 8.5.0 through 8.5.100. Other versions that have reached end of support may also be affected.
Users are recommended to upgrade to version 11.0.23, 10.1.56 or 9.0.119, which fix the issue. |
| It is possible to bypass the Kerberos pre-authentication check in Apache Kerby by sending a PA-DATA with an unrecognized or unsupported type. Users are recommended to upgrade to version 2.1.2, which fixes this issue. |
| In the Linux kernel, the following vulnerability has been resolved:
bpf: Switch CONFIG_CFI_CLANG to CONFIG_CFI
This was renamed in commit 23ef9d439769 ("kcfi: Rename CONFIG_CFI_CLANG
to CONFIG_CFI") as it is now a compiler-agnostic option. Using the wrong
name results in the code getting compiled out. Meaning the CFI failures
for btf_dtor_kfunc_t would still trigger. |
| Backpropagate is a Python library for fine-tuning large language models on a single GPU. In versions 1.1.0 and 1.1.1, the optional Reflex web UI exposes a training control plane without authentication: dataset upload, model load, training start/stop, multi-run orchestration, GGUF export, and HuggingFace Hub push. The CLI accepts two operator-facing flags intended as security controls: --auth user:pass — documented as "require HTTP Basic authentication on every request to the UI." and--share — documented as "expose the UI on a public address; requires --auth." When --auth user:pass is passed, the CLI prints Auth: enabled (user: <username>) to confirm to the operator that authentication is active, then exports BACKPROPAGATE_UI_AUTH=user:pass to the subprocess that launches the Reflex backend. The Reflex backend (backpropagate/ui_app/**) never reads BACKPROPAGATE_UI_AUTH. No authentication middleware is registered. No request-level guard runs. No WebSocket upgrade guard runs. Any client that reaches the bound port — local or remote, depending on whether --share is used — has full UI access. An inline comment at backpropagate/cli.py:1217-1218 in the v1.1.0 source documents the gap: "For Phase 1 the variable is exported but Reflex doesn't read it yet." This comment was internal-facing; the user-facing documentation (README, CHANGELOG, SHIP_GATE) advertised the contract as enforced. An attacker who reaches the bound port can read uploaded datasets, trigger arbitrary training runs against any local base models as well as read their paths, trigger HuggingFace Hub pushes and cause disk-fill DoS. This issue has been fixed in version 1.2.0. If developers cannot immediately upgrade to 1.2.0 run backprop ui with no flags so it binds to localhost, use SSH port-forwarding (ssh -L 7860:localhost:7860 <training-host>) instead of --share for remote access, and audit any host previously launched with --share, re-issuing any HF tokens used during those sessions. |
| Mitigation bypass in the DOM: Security component. This vulnerability was fixed in Firefox 152 and Thunderbird 152. |
| An Improperly Implemented Security Check for Standard vulnerability [CWE-358] in FortiOS version 7.6.0, version 7.4.7 and below, 7.0 all versions, 6.4 all versions and FortiProxy version 7.6.1 and below, version 7.4.8 and below, 7.2 all versions, 7.0 all versions may allow a remote unauthenticated user to bypass the DNS filter via Apple devices. |
| Inappropriate implementation in Keyboard in Google Chrome prior to 149.0.7827.53 allowed a remote attacker to inject arbitrary scripts or HTML (UXSS) via a crafted HTML page. (Chromium security severity: Medium) |
| Inappropriate implementation in WebAPKs in Google Chrome on Android prior to 149.0.7827.53 allowed a remote attacker to perform domain spoofing via a crafted WebAPK. (Chromium security severity: Medium) |
| Inappropriate implementation in Extensions in Google Chrome prior to 149.0.7827.53 allowed an attacker who convinced a user to install a malicious extension to bypass same origin policy via a crafted Chrome Extension. (Chromium security severity: Medium) |
| Inappropriate implementation in Downloads in Google Chrome prior to 149.0.7827.53 allowed a remote attacker to bypass navigation restrictions via a crafted HTML page. (Chromium security severity: Low) |
| Mbed TLS v3.3.0 up to 3.6.5 and 4.0.0 allows Algorithm Downgrade. |
| Inappropriate implementation in Extensions in Google Chrome prior to 149.0.7827.53 allowed a remote attacker who had compromised the renderer process to perform privilege escalation via a crafted HTML page. (Chromium security severity: Low) |
| free5GC is an open-source implementation of the 5G core network. Prior to 4.2.2, the AMF in Free5GC does not verify the UE Security Capabilities received in NGAP PathSwitchRequest messages against its locally stored values, as mandated by 3GPP TS 33.501 §6.7.3.1. A malicious gNB can overwrite the AMF's stored UE security capabilities with arbitrary values, which are then propagated in PathSwitchRequest Acknowledge messages and subsequent Handover Request messages. This leads to persistent handover denial-of-service for affected UEs. This vulnerability is fixed in 4.2.2. |
