Vulnerabilities
112 CVEs · NVD, GitHub Advisories, CISA KEV, FIRST EPSS, GitHub PoC repos
| CVE | Vulnerability | CVSS | EPSS | Flags | Affected | Exposure | Published |
|---|---|---|---|---|---|---|---|
| CVE-2026-73309 | Authentication bypass in XenForo OAuth2 token endpoint XenForo before 2.3.13 contains an unauthenticated authentication bypass (CWE-697) in its OAuth2 token endpoint, rated critical (CVSS 4.0: 9.1). The flaw arises from PHP truthy evaluation: when an attacker submits empty values for the client_secret and code_verifier parameters, the empty strings are treated as false and both client-secret validation and PKCE code-verifier validation are skipped entirely. As a result, an attacker who obtains a valid authorization code (for example by intercepting it during a legitimate redirect) can exchange it for a token pair without proving client identity or honoring the PKCE commitment, gaining access and refresh tokens with the high confidentiality and integrity impact reflected in the CVSS scoring. Only XenForo deployments running versions before 2.3.13 that expose the OAuth2 token endpoint (i.e., act as OAuth2 authorization servers) are affected. No in-the-wild exploitation is documented so far: one public proof-of-concept exists on GitHub, the issue is not in CISA's KEV catalog, and EPSS assigns a 0.5% probability of exploitation within 30 days. Do: Upgrade to XenForo 2.3.13 or later. Until patched, add a mitigation that rejects empty client_secret and code_verifier values at the OAuth2 token endpoint (e.g., via WAF rule or code patch) and monitor for tokens issued without proper client authentication. Also review OAuth2 client configurations and recently issued tokens, and enforce strict redirect-URI and TLS hygiene, since the bypass matters most when authorization codes can be intercepted. | 9.1 | <1% | PoC |
| moderatelikely thousands to low tens of thousands of forum installations (subset of XenForo's commercial install base that runs an affected version and exposes the… | |
| CVE-2026-19931 +1 in the same advisory: …18924 | Cross-user connection reuse flaw in libcurl Negotiate authentication Libcurl wrongly reuses an HTTP connection that was set up for a hostname using Negotiate authentication when the initial request to that host was made with empty credentials, so a connection already authenticated as one user can be handed to a different user's request (tracked as CWE-488, Exposure of Data Element to Wrong Session). The flaw is triggered when a client first contacts a host over Negotiate (Kerberos/SPNEGO) HTTP authentication with no credentials, and then subsequent requests as different users are sent over that reused, already-authenticated connection. An attacker gains cross-user identity mixups: user B's requests travel over user A's authenticated connection, so data can be disclosed to, or acted on under, the wrong identity, with the CVSS vector rating confidentiality, integrity and availability impact all high and the flaw critical (9.8) with no privileges or user interaction required. Any application or tool that uses libcurl is affected when it performs Negotiate HTTP authentication for multiple users against the same host; this includes the curl command-line tool and the very large ecosystem of operating systems and products that bundle or embed libcurl. No public proof of concept or in-the-wild exploitation is known, it is not in CISA KEV, and EPSS currently estimates a 0.8 percent probability of exploitation within 30 days. Do: Upgrade curl/libcurl to the fixed release named in the curl project's security advisory, and audit which installed or embedded libcurl builds your estate carries. As mitigations, avoid making Negotiate-authenticated requests with empty credentials, or prevent connection reuse (for example, use fresh connections per user or disable the connection cache) when multiple users authenticate against the same host. Deployments that never use Negotiate/Kerberos HTTP authentication are not practically affected. | 9.8 group max | 1% | PoC |
| massbillions of bundled libcurl installs ship with major operating systems, but direct exposure is limited to Negotiate/Kerberos HTTP-auth users, plausibly on the… | |
| CVE-2026-19490 | Remote Authentication Bypass in Citrix NetScaler ADC and NetScaler Gateway Citrix NetScaler ADC and NetScaler Gateway contain an authentication-bypass vulnerability (CWE-288, 'using an alternate path or channel') that an unauthenticated remote threat actor can exploit. The flaw is triggerable when the appliance is configured as an AAA virtual server or as a Gateway, including SSL VPN, ICA Proxy, CVPN, or RDP Proxy deployments, allowing the attacker to bypass authentication without valid credentials. A successful bypass could give an attacker access to VPN-protected or AAA-gated resources as an authenticated user; no CVSS score has been published yet. Organizations running affected NetScaler appliances in these configurations are exposed, and affected version ranges are not specified in the available data, so defenders should consult Citrix advisory AL26-019. The flaw was added to CISA's KEV on 2026-09-09, indicating exploitation in the wild; ransomware use is unknown, no public PoC is known, and EPSS assigns a 3.4% probability of exploitation within 30 days (88th percentile). Do: Prioritize applying vendor fixes or mitigations per Citrix advisory AL26-019 in line with CISA BOD 26-04, focusing first on internet-facing appliances configured as AAA virtual servers or Gateways (SSL VPN, ICA Proxy, CVPN, RDP Proxy). Until patched, restrict internet exposure and review VPN/AAA authentication logs for signs of unauthenticated access, following CISA's Forensics Triage Requirements if compromise is suspected. | 9.3 | 6% | KEV PoC |
| largeon the order of 10,000-100,000 internet-exposed NetScaler ADC/Gateway appliances | |
| CVE-2026-9390 +1 in the same advisory: …9487 | XML::Sig versions before 0.71 for Perl allow XPath injection in ID lookup. XML::Sig versions before 0.71 for Perl allow XPath injection in ID lookup. verify() and _get_signed_xml() in lib/XML/Sig.pm build XPath expressions by concatenating the SignedInfo/Reference/@URI value read from the document being verified. The value is neither escaped nor checked against the NCName grammar that XML requires of an ID, so a URI containing a single quote closes the string literal in the generated expression and appends arbitrary XPath operators. A crafted URI can make the lookup match elements the reference does not name, or every element in the document, so which node is selected for digest verification is decided by the injected expression rather than by the reference. NVD description · AI analysis pending | 9.1 | <1% |
| — | ||
| CVE-2026-65883 | Joomla Extension - aimy-extensions.com - RCE via PHP object injection in Aimy Captcha-Less Form Guard 18.0 - 20.0 - A forged clfgd field allows PHP objection in Joomla Extension - aimy-extensions.com - RCE via PHP object injection in Aimy Captcha-Less Form Guard 18.0 - 20.0 - A forged clfgd field allows PHP objection injection and thereby remote code execution. NVD description · AI analysis pending | 10.0 | <1% |
| — | ||
| CVE-2026-64268 | In the Linux kernel, the following vulnerability has been resolved: In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: bound Read Response placement to the RREAD length In drivers/infiniband/sw/siw/siw_qp_rx.c, siw_proc_rresp() places each inbound Read Response DDP segment at sge->laddr + wqe->processed and then accumulates wqe->processed, but it never checks the running total against the sink buffer length on continuation segments. siw_check_sge() resolves and validates the sink memory only on the first fragment (the if (!*mem) branch), and siw_rresp_check_ntoh() compares the cumulative length against wqe->bytes only on the final segment (the !frx->more_ddp_segs guard). A connected siw peer that answers an outstanding RREAD with Read Response segments that keep the DDP Last flag clear, carrying more total payload than the RREAD requested, drives wqe->processed past the validated sink buffer; the next siw_rx_data() call writes out of bounds at sge->laddr + wqe->processed. siw runs iWARP over ordinary routable TCP, so the peer is the remote end of an established RDMA connection and needs no local privilege. Bound every segment before placement, exactly as siw_proc_send() and siw_proc_write() already do for their tagged and untagged paths, and terminate the connection with a base-or-bounds DDP error when the Read Response would overrun the sink buffer. This is the second receive-path length fix for this file. A separate change rejects an MPA FPDU length that underflows the per-fragment remainder in the header decode; that guard does not cover this case, because here each individual segment length is self-consistent and only the accumulated placement offset overruns the buffer. NVD description · AI analysis pending | 9.8 group max | <1% |
| — | ||
| CVE-2026-64232 +1 in the same advisory: …64216 | In the Linux kernel, the following vulnerability has been resolved: In the Linux kernel, the following vulnerability has been resolved: block: recompute nr_integrity_segments in blk_insert_cloned_request blk_insert_cloned_request() already recomputes nr_phys_segments against the bottom queue, because "the queue settings related to segment counting may differ from the original queue." The exact same reasoning applies to integrity segments: a stacked driver's underlying queue can have tighter virt_boundary_mask, seg_boundary_mask, or max_segment_size than the top queue, in which case blk_rq_count_integrity_sg() against the bottom queue produces a different count than the cached rq->nr_integrity_segments inherited from the source request by blk_rq_prep_clone(). When the cached count is lower than the bottom queue's actual count, blk_rq_map_integrity_sg() trips BUG_ON(segments > rq->nr_integrity_segments); on dispatch. The same families of stacked setups that motivated the existing nr_phys_segments recompute -- dm-multipath fanning out to nvme-rdma in particular -- can produce this. Mirror the nr_phys_segments handling: when the request carries integrity, recompute nr_integrity_segments against the bottom queue and reject the request if it exceeds the bottom queue's max_integrity_segments. blk_rq_count_integrity_sg() and queue_max_integrity_segments() are both already available via , which blk-mq.c includes. This closes a latent gap in the stacking contract and brings the integrity-segment accounting in line with the existing phys-segment accounting. NVD description · AI analysis pending | 9.8 | <1% |
| — | ||
| CVE-2026-63359 | The Appriss Insights (Equifax) Victim Information Notification Exchange (VINE) applications allow an unauthenticated attacker to send a specially-crafted reques The Appriss Insights (Equifax) Victim Information Notification Exchange (VINE) applications allow an unauthenticated attacker to send a specially-crafted request to bypass the login page, access other users' credentials, take over other user accounts, access sensitive PII, and dump other information from the database. NVD description · AI analysis pending | 9.3 | <1% |
| — | ||
| CVE-2026-64125 | In the Linux kernel, the following vulnerability has been resolved: In the Linux kernel, the following vulnerability has been resolved: net: bcmgenet: keep RBUF EEE/PM disabled Setting RBUF_EEE_EN | RBUF_PM_EN in RBUF_ENERGY_CTRL breaks the RX path on GENET hardware once MAC EEE becomes active. RX traffic stops flowing while the link stays up and the usual descriptor/RX error counters remain quiet. In that state the MAC still accepts frames (rbuf_ovflow_cnt keeps climbing) but RBUF no longer forwards them to DMA, so rx_packets is no longer incremented at the netdev level. On some boards the corruption ends up as a paging fault in skb_release_data via bcmgenet_rx_poll on an LPI exit. Reproduced on Pi 4B (BCM2711 + BCM54213PE) and confirmed by Florian Fainelli on an internal Broadcom 4908-family board with the same crash signature. RBUF_PM_EN is not publicly documented. This shows up more often now that phy_support_eee() enables EEE by default, but it also affects older kernels as soon as TX LPI is turned on via ethtool, so it is not specific to recent changes. Always clear RBUF_EEE_EN | RBUF_PM_EN in bcmgenet_eee_enable_set so the bits stay off across resets. UMAC and TBUF setup is left alone so TX-side EEE keeps working. NVD description · AI analysis pending | 9.8 group max | <1% |
| — |