ThreatsDay: Adobe RCE, DNS Wallet Theft, NVIDIA Container Escape, Self-Healing Backdoor + 23 More · 2h Silent Lynx Exploitat WinRAR Vitium ad Instruendum Reverse Shell in Attacis Regni CIS · 5h NGINX Corrigit 5 Vitia, Inclusa Possibili RCE et Bug TLS Qui Potest Saltare Client-Cert Checks · 8h Next.js Emittit Emendationem Extra Ordinem pro Duobus Criticis RCE Defectibus in Caching et SVG Processu · 8h Drupal Patches Criticum Core RCE Vitium Sine Login Via Contributis Modulis · 9h Vulnerabilitas in software Sparx Systems Enterprise Architect · 9h Curl verhelpt 'high' RCE-kwetsbaarheid gevonden door Anthropic · 9h Vulnerabilitates in Slican telephonis · 10h Palo Alto Networks monet ad abusum vulnerabilitatis in ignibus securitatis · 13h Cisco nuntiat activum abusus criticae vulnerabilitatis in Secure Email Gateway · 14h ThreatsDay: Adobe RCE, DNS Wallet Theft, NVIDIA Container Escape, Self-Healing Backdoor + 23 More · 2h Silent Lynx Exploitat WinRAR Vitium ad Instruendum Reverse Shell in Attacis Regni CIS · 5h NGINX Corrigit 5 Vitia, Inclusa Possibili RCE et Bug TLS Qui Potest Saltare Client-Cert Checks · 8h Next.js Emittit Emendationem Extra Ordinem pro Duobus Criticis RCE Defectibus in Caching et SVG Processu · 8h Drupal Patches Criticum Core RCE Vitium Sine Login Via Contributis Modulis · 9h Vulnerabilitas in software Sparx Systems Enterprise Architect · 9h Curl verhelpt 'high' RCE-kwetsbaarheid gevonden door Anthropic · 9h Vulnerabilitates in Slican telephonis · 10h Palo Alto Networks monet ad abusum vulnerabilitatis in ignibus securitatis · 13h Cisco nuntiat activum abusus criticae vulnerabilitatis in Secure Email Gateway · 14h
🛡️
ACyber Sentinel Turma Aestimationis Securitatis
← Redire
⚡ Renuntiatio

CISA Significat Tres Vulnerabilitates Kernel Linux Invenientes in Naturam

Agens Civitatum Foederatarum pro Cybersecuritate et Securitate Infrastructurae (CISA) die Veneris tres defectus securitatis quae kernel Linux afficiunt ad suum Catalogum Vulnerabilitatum Cognitarum Exploitatarum (KEV) addidit, documentis activae exploitationis citatis.

Vulnerabilitates infra enumeratae sunt -

CVE-2025-39682 (CVSS score: 9.8) - Vulnerabilitas in iniqua recognitione condicionum insolitarum vel exceptionalium in via receptionis TLS, quae permittit utentes localiter authenticos ad divulgationem memoriae vel negationem servitii (DoS) excitandam.

CVE-2026-53266 (CVSS score: 8.8) - Vulnerabilitas in scripto extra fines in via redefinitionis Protocoli Resolutionis Adressae (ARP) ebtables Source Network Address Translation (SNAT), quae permittit utentem localem ad excitandum systematis comportamentum inopinatum, DoS, vel escalationem privilegii localis.

CVE-2025-39964 (CVSS score: 7.8) - Vulnerabilitas in condicione certaminis quae permittit concurrentes scripta ad eundem socket AF_ALG, permittens utentem localem ad systema frangendum vel ad corruptione eventuum operationum cryptographicorum, causando DoS vel quaestiones integritatis datae.

Nunc non sunt details de modo quo tres vulnerabilitates in natura exploduntur, et si partem unius catenae impugnationis armantur. Tamen, Red Hat advisoria pro omnibus defectibus ad diem 19 Septembris 2026, hora 2 a.m. UTC, renovavit ut activam exploitationem agnoscat.

"Hic CVE est summum periculum et nota sunt publica exploita quae hanc vulnerabilitatem utuntur," inquit Red Hat. "Hanc vulnerabilitatem cum alta prioritate adde."

Secundum Directivam Operationalem Vinculum (BOD) 26-04: Prioritizatio Update Securitatis Fundata in Periculo, agens Fœderalis Civilis Executivus (FCEB) commendatur ut necessarias emendationes adhibeat ante diem 21 Septembris 2026.

Haec evolutio fit cum investigator securitatis nomine Asim Manizada quattuor defectus escalationis privilegii localis quae kernel Linux afficiunt detexit: CVE-2026-80844 (alias DirtyAH6), CVE-2026-81000 (alias TUNderflow), CVE-2026-68121 (alias PPPoEject), et CVE-2026-74469 (alias DiagSpill).

Hanc artem iucundam invenisti? Sequere nos in Google News, Twitter et LinkedIn ut plura contenta exclusiva quae publicamus legas.

Vulnerabilitates Relatae

CVE-2026-81000 CVSS 7.8 HIGH Received
CVE-2026-81000 - net: tun: bound receive headroom
In the Linux kernel, the following vulnerability has been resolved: net: tun: bound receive headroom tun_get_user() uses tun->align both as skb headroom and when choosing how much packet data to keep linear. OVS can propagate an oversized headroom request from another port to TUN or TAP. When align is larger than the usable space in a one-page skb head, SKB_MAX_HEAD(align) underflows and the result becomes negative when stored in good_linear. That value later wraps when assigned to the size_t linear variable, and tun_alloc_skb() can place skb->data outside the allocated head. Bound the headroom stored by TUN to the one-page skb-head budget and the largest non-sentinel 16-bit skb header offset. Leave one linear byte for raw TUN and a complete Ethernet header for TAP, including NET_IP_ALIGN. Also pull the raw-TUN protocol byte and the TAP Ethernet header before accessing them, so these checks remain safe for nonlinear skbs supplied by other allocation paths.
CVE-2026-80844 NA Received
CVE-2026-80844 - xfrm: ah6: validate routing header segments_left
In the Linux kernel, the following vulnerability has been resolved: xfrm: ah6: validate routing header segments_left AH6 rearranges routing-header addresses before computing or verifying the ICV. ipv6_rearrange_rthdr() assumes that segments_left is not larger than the number of addresses described by the routing header's hdrlen field. That assumption does not hold for raw IPv6 HDRINCL packets. A packet with hdrlen equal to 2 describes one address, but can carry an arbitrary segments_left value. With segments_left equal to 255, the function moves its address pointer 4,064 bytes backwards and passes a 4,064-byte length to memmove(), resulting in an out-of-bounds access. Validate the invariant locally before modifying the routing header or performing any address-pointer arithmetic, and propagate malformed-header errors to the existing AH6 input and output error paths.
CVE-2026-74469 CVSS 8.8 HIGH Received
CVE-2026-74469 - sctp: prevent peer transport count overflow
In the Linux kernel, the following vulnerability has been resolved: sctp: prevent peer transport count overflow sctp_assoc_add_peer() increments the association's 16-bit transport_count for every new unique peer. Adding the 65,536th transport wraps the count to zero. SCTP sock_diag uses transport_count to reserve the INET_DIAG_PEERS payload, then copies one sockaddr_storage for every entry in transport_addr_list. After the wrap, a diagnostic dump reserves an empty payload and writes 8 MiB of peer addresses past the skb tail. Reject a new unique peer when transport_count has reached U16_MAX. Perform the check after the existing-peer lookup so a duplicate address continues to return its existing transport at the limit.
CVE-2026-68121 CVSS 7.8 HIGH Received
CVE-2026-68121 - pppoe: reload header pointer after dev_hard_header()
In the Linux kernel, the following vulnerability has been resolved: pppoe: reload header pointer after dev_hard_header() pppoe_sendmsg() saves a pointer to the PPPoE header before calling dev_hard_header(). Device header callbacks are allowed to reallocate the skb head, invalidating pointers into it. This can happen when a send is blocked in copy_from_user() while the first non-Ethernet port is added to an empty team device. The team's delegated GRE header callback then expands the skb head. PPPoE subsequently writes six bytes through the stale pointer into the freed head. Reload the PPPoE header through the skb's network-header offset after device header creation. pskb_expand_head() updates that offset when it relocates the head.
CVE-2026-53266 CVSS 8.8 HIGH Analyzed
CVE-2026-53266 - Linux Kernel Out-of-Bounds Write Vulnerability - [Actively Exploited]
In the Linux kernel, the following vulnerability has been resolved: netfilter: bridge: make ebt_snat ARP rewrite writable The ebtables SNAT target keeps the Ethernet source address rewrite behind skb_ensure_writable(skb, 0). This is intentional: at the bridge ebtables hooks the Ethernet header is addressed through skb_mac_header()/eth_hdr(), while skb->data points at the Ethernet payload. Asking skb_ensure_writable() for ETH_HLEN bytes would check the payload, not the Ethernet header, and would reintroduce the small packet regression fixed by commit 63137bc5882a. However, the optional ARP sender hardware address rewrite is different. It writes through skb_store_bits() at an offset relative to skb->data: skb_store_bits(skb, sizeof(struct arphdr), info->mac, ETH_ALEN) skb_header_pointer() only safely reads the ARP header; it does not make the later sender hardware address range writable. If that range is still held in a nonlinear skb fragment backed by a splice-imported file page, skb_store_bits() maps the frag page and copies the new MAC address directly into it. Ensure the ARP SHA range is writable before reading the ARP header and before calling skb_store_bits().
CVE-2025-39964 CVSS 7.8 HIGH Analyzed
CVE-2025-39964 - Linux Kernel Race Condition Vulnerability - [Actively Exploited]
In the Linux kernel, the following vulnerability has been resolved: crypto: af_alg - Disallow concurrent writes in af_alg_sendmsg Issuing two writes to the same af_alg socket is bogus as the data will be interleaved in an unpredictable fashion. Furthermore, concurrent writes may create inconsistencies in the internal socket state. Disallow this by adding a new ctx->write field that indiciates exclusive ownership for writing.
CVE-2025-39682 CVSS 9.8 CRITICAL Analyzed
CVE-2025-39682 - Linux Kernel Improper Check for Unusual or Exceptional Conditions Vulnerability - [Actively Exploited]
In the Linux kernel, the following vulnerability has been resolved: tls: fix handling of zero-length records on the rx_list Each recvmsg() call must process either - only contiguous DATA records (any number of them) - one non-DATA record If the next record has different type than what has already been processed we break out of the main processing loop. If the record has already been decrypted (which may be the case for TLS 1.3 where we don't know type until decryption) we queue the pending record to the rx_list. Next recvmsg() will pick it up from there. Queuing the skb to rx_list after zero-copy decrypt is not possible, since in that case we decrypted directly to the user space buffer, and we don't have an skb to queue (darg.skb points to the ciphertext skb for access to metadata like length). Only data records are allowed zero-copy, and we break the processing loop after each non-data record. So we should never zero-copy and then find out that the record type has changed. The corner case we missed is when the initial record comes from rx_list, and it's zero length.