CVE Watch22 de out. de 2026

CVE-2026-20179

Multiple Cisco products are affected by a vulnerability in the Snort 3 Generic Routing Encapsulation (GRE) Detection Engine that could allow

CVSS

5.8

Média

EPSS

0.5%

p43

KEV

—

Exploit Today

0-100

Publicado: 21 de out. de 2026 · Última mod.: 22 de out. de 2026 · CWE-128

EPSS · 30d

0.4%EPSS · 30 dias0.5%

2026-10-222026-11-07

Descrição técnica

Multiple Cisco products are affected by a vulnerability in the Snort 3 Generic Routing Encapsulation (GRE) Detection Engine that could allow an unauthenticated, remote attacker to cause the Snort 3 Detection Engine to restart, resulting in an interruption of packet inspection. This vulnerability is due to incomplete error checking when Snort 3 parses GRE packets. An attacker could exploit this vulnerability by sending a crafted GRE packet to a targeted device to be parsed by Snort. A successful exploit could allow the attacker to cause the Snort 3 Detection Engine to restart unexpectedly, resulting in a DoS condition.

Referências oficiais

sec.cloudapps.cisco.comhttps://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-snort3-misc-dos-6mB22qAK

CVEs relacionados

CVECVSSEPSSKEVRExploitTítuloMod.

CVE-2026-169098.8 ALT

36.2%

——11IBM AIX 7.2, and 7.3 and IBM PowerVM VIOS 4.1 could allow a remote attacker to execute arbitrary code due to an off-by-one error in bounds checking.13d CVE-2026-549055.5 MÉD

4.5%

——1concurrent-ruby is a modern concurrency tools for Ruby. Prior to 1.3.7, Concurrent::ReentrantReadWriteLock can incorrectly grant a write lock after one thread acquires the read lock 32,768 times. The lock stores a thread's local read and write hold counts in one integer. The low 15 bits are used for the read hold count, and bit 15 is used as WRITE_LOCK_HELD. After 32,768 reentrant read acquisitions, the local read count crosses into the write-lock bit. try_write_lock then treats the thread as already holding a write lock and returns true without setting the global RUNNING_WRITER bit. This breaks the core mutual-exclusion guarantee: the caller is told it has a write lock, but other threads can still hold or acquire read locks at the same time. This vulnerability is fixed in 1.3.7.14d