🚨 CVE-2026-58436
ParseAcceptLanguage quadratic-time DoS via Locale middleware on unauthenticated requests
🎖@cveNotify
ParseAcceptLanguage quadratic-time DoS via Locale middleware on unauthenticated requests
🎖@cveNotify
🚨 CVE-2026-58438
Cross-repository IDOR in issue-dependency removal lets an attacker tamper with and comment on private repos they cannot access
🎖@cveNotify
Cross-repository IDOR in issue-dependency removal lets an attacker tamper with and comment on private repos they cannot access
🎖@cveNotify
🚨 CVE-2026-58440
Webhooks created by a collaborator keep firing after their repo access is revoked → ongoing real-time exfiltration of private repo content (incomplete revocation cleanup in `DeleteCollaboration`)
🎖@cveNotify
Webhooks created by a collaborator keep firing after their repo access is revoked → ongoing real-time exfiltration of private repo content (incomplete revocation cleanup in `DeleteCollaboration`)
🎖@cveNotify
🚨 CVE-2026-58444
Personal access token scope enforcement bypass on the repository home page (`GET /{owner}/{repo}`) discloses private repository contents
🎖@cveNotify
Personal access token scope enforcement bypass on the repository home page (`GET /{owner}/{repo}`) discloses private repository contents
🎖@cveNotify
🚨 CVE-2026-58445
Cross-repository label-ID enumeration oracle via unscoped DeleteIssueLabel API
🎖@cveNotify
Cross-repository label-ID enumeration oracle via unscoped DeleteIssueLabel API
🎖@cveNotify
🚨 CVE-2026-58508
Two SSRF vulnerabilities in Gitea migration/mirror (DNS rebinding + missing re-validation)
🎖@cveNotify
Two SSRF vulnerabilities in Gitea migration/mirror (DNS rebinding + missing re-validation)
🎖@cveNotify
🚨 CVE-2026-58510
GHSA-8fwc-qjw5-rvgp ClearRepoWatches fix not applied to API EditRepo path — sister code path retains stale watches on public->private
🎖@cveNotify
GHSA-8fwc-qjw5-rvgp ClearRepoWatches fix not applied to API EditRepo path — sister code path retains stale watches on public->private
🎖@cveNotify
🚨 CVE-2026-59763
Unbounded Arch package file metadata can cause resource amplification in Gitea package uploads
🎖@cveNotify
Unbounded Arch package file metadata can cause resource amplification in Gitea package uploads
🎖@cveNotify
🚨 CVE-2026-59765
SSRF via Migration Asset Downloads Bypasses hostmatcher — Reads Internal Files and Cloud Metadata
🎖@cveNotify
SSRF via Migration Asset Downloads Bypasses hostmatcher — Reads Internal Files and Cloud Metadata
🎖@cveNotify
🚨 CVE-2026-12236
The Bluetooth host GATT client function parse_read_std_char_desc() in subsys/bluetooth/host/gatt.c parses an ATT Read By Type Response received from a remote GATT server during BT_GATT_DISCOVER_STD_CHAR_DESC discovery. The per-entry stride rsp->len is taken directly from the peer's PDU, and the parse loop both tests its exit condition (length >= rsp->len) and advances (length -= rsp->len, pdu += rsp->len) using that value. The minimum value of rsp->len was never validated before the loop.
A malicious or malfunctioning peer can reply with rsp->len = 0. Because length is unsigned and never decreases, the loop condition stays true forever and the read pointer never advances; as long as the body is at least a few bytes with a non-zero handle and a matching descriptor UUID, the host repeatedly re-parses the same bytes and invokes the discovery callback, never terminating. This hangs the Bluetooth host processing thread (CWE-835, loop with unreachable exit condition).
The condition is reachable by any connected peer once the local device initiates standard-descriptor-value discovery; GATT discovery does not require bonding or encryption, so an unauthenticated adjacent attacker that the device connects to can trigger it. The impact is denial of service of the Bluetooth subsystem (and likely a watchdog reset on constrained targets); there is no memory disclosure or corruption.
The fix adds a rsp->len < sizeof(struct bt_att_data) check before the loop, rejecting under-length responses so the stride is always non-zero and the loop terminates. The sibling parsers parse_include() and parse_characteristic() already validated rsp->len and are unaffected.
🎖@cveNotify
The Bluetooth host GATT client function parse_read_std_char_desc() in subsys/bluetooth/host/gatt.c parses an ATT Read By Type Response received from a remote GATT server during BT_GATT_DISCOVER_STD_CHAR_DESC discovery. The per-entry stride rsp->len is taken directly from the peer's PDU, and the parse loop both tests its exit condition (length >= rsp->len) and advances (length -= rsp->len, pdu += rsp->len) using that value. The minimum value of rsp->len was never validated before the loop.
A malicious or malfunctioning peer can reply with rsp->len = 0. Because length is unsigned and never decreases, the loop condition stays true forever and the read pointer never advances; as long as the body is at least a few bytes with a non-zero handle and a matching descriptor UUID, the host repeatedly re-parses the same bytes and invokes the discovery callback, never terminating. This hangs the Bluetooth host processing thread (CWE-835, loop with unreachable exit condition).
The condition is reachable by any connected peer once the local device initiates standard-descriptor-value discovery; GATT discovery does not require bonding or encryption, so an unauthenticated adjacent attacker that the device connects to can trigger it. The impact is denial of service of the Bluetooth subsystem (and likely a watchdog reset on constrained targets); there is no memory disclosure or corruption.
The fix adds a rsp->len < sizeof(struct bt_att_data) check before the loop, rejecting under-length responses so the stride is always non-zero and the loop terminates. The sibling parsers parse_include() and parse_characteristic() already validated rsp->len and are unaffected.
🎖@cveNotify
GitHub
Bluetooth: Host: GATT: Fix missing check for minimum read response size · zephyrproject-rtos/zephyr@494283d
There's a for loop in parse_read_std_char_desc() that'll go on forever if
rsp->len is 0. Add a minimum length check to the beginning of it to avoid
this issue.
Signed-off-by...
rsp->len is 0. Add a minimum length check to the beginning of it to avoid
this issue.
Signed-off-by...
🚨 CVE-2026-73669
The Signify Philips Hue Bridge Pro firmware embeds a Mosquitto MQTT broker service that listens on all network interfaces without authentication. An unauthenticated attacker with network access to the MQTT service on a vulnerable system can read data and control connected lights. Fixed in 1.77.2071318010.
🎖@cveNotify
The Signify Philips Hue Bridge Pro firmware embeds a Mosquitto MQTT broker service that listens on all network interfaces without authentication. An unauthenticated attacker with network access to the MQTT service on a vulnerable system can read data and control connected lights. Fixed in 1.77.2071318010.
🎖@cveNotify
🚨 CVE-2026-72810
SiYuan versions before v3.7.4 contain a publish-boundary bypass vulnerability in WebSocket broadcast sessions that allows anonymous readers to receive unfiltered edits. Attackers can establish a WebSocket connection to the publish surface and passively receive real-time content events including password-protected and forbidden documents without authentication.
🎖@cveNotify
SiYuan versions before v3.7.4 contain a publish-boundary bypass vulnerability in WebSocket broadcast sessions that allows anonymous readers to receive unfiltered edits. Attackers can establish a WebSocket connection to the publish surface and passively receive real-time content events including password-protected and forbidden documents without authentication.
🎖@cveNotify
GitHub
Publish-boundary bypass via WebSocket broadcast: anonymous readers receive a live unfiltered feed of all edits including protected/forbidden…
**CVE:** This vulnerability corresponds to [CVE-2026-72810](https://nvd.nist.gov/vuln/detail/CVE-2026-72810).
### Summary
WebSocket sessions established through the publish surface (port 6808...
### Summary
WebSocket sessions established through the publish surface (port 6808...
🚨 CVE-2026-72811
SiYuan versions <= v3.7.2 contain a SQL injection vulnerability in the backlink/mention search query (kernel/model/backlink.go), which concatenates stored block metadata (title, name, alias, anchor text) and the client-supplied keyword into a SQL MATCH/search statement while escaping only the double-quote character and not the single quote. A single quote in the client keyword (first-order, reachable by an anonymous or RoleReader user on the publish surface) or in stored document metadata (second-order) breaks out of the string literal. Because the query runs on the main read-write siyuan.db handle via a statement-stacking-capable driver, an attacker can execute arbitrary SQL, enabling cross-notebook read and write. Fixed in v3.7.4.
🎖@cveNotify
SiYuan versions <= v3.7.2 contain a SQL injection vulnerability in the backlink/mention search query (kernel/model/backlink.go), which concatenates stored block metadata (title, name, alias, anchor text) and the client-supplied keyword into a SQL MATCH/search statement while escaping only the double-quote character and not the single quote. A single quote in the client keyword (first-order, reachable by an anonymous or RoleReader user on the publish surface) or in stored document metadata (second-order) breaks out of the string literal. Because the query runs on the main read-write siyuan.db handle via a statement-stacking-capable driver, an attacker can execute arbitrary SQL, enabling cross-notebook read and write. Fixed in v3.7.4.
🎖@cveNotify
GitHub
SQL injection in backlink/mention search via unescaped stored and client input (publish mode): first-order (client keyword) and…
**CVE:** This vulnerability corresponds to [CVE-2026-72811](https://nvd.nist.gov/vuln/detail/CVE-2026-72811).
### Summary
The backlink/mention search query (`kernel/model/backlink.go`) concat...
### Summary
The backlink/mention search query (`kernel/model/backlink.go`) concat...