| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| DBI versions before 1.652 for Perl allow a heap out-of-bounds write via an unvalidated numeric placeholder that sets the binder counter in preparse.
preparse reserves seven output bytes per input byte, the width of the longest ':p99999' expansion. The ':N' branch parses the number with `atoi(src)` and assigns it to the binder counter with no range check, so a statement containing ':2147483648' leaves the counter negative (-2147483648 with glibc, where atoi wraps). Each following '?' then expands through `sprintf(start, ":p%d", idx++)` to ':p-2147483648', 14 bytes with the terminating NUL where the buffer budgets 7. The placeholder limit added in 1.650 tests the counter against 99,999, which a negative counter passes.
Any caller that preparses an untrusted statement into ':pN' style placeholders gets a heap out-of-bounds write that grows with the number of '?' marks following the poisoned placeholder. The '?' and '%s' return styles compare the parsed number against the expected sequence and error out, and are unaffected. |
| As part of Cisco's ongoing commitment to proactive security and product quality, the Cisco Catalyst SD-WAN engineering team has conducted a comprehensive internal security review. This review resulted in software hardening releases that address multiple internally discovered vulnerabilities.
The vulnerabilities tracked by CVE-2026-20313 are related to Improper link resolution before file access issues that are grouped under the Common Weakness Enumeration (CWE) CWE-1284. |
| An improper access control vulnerability exists where an authenticated non-administrative application user could potentially view settings outside of their assigned scope. |
| rsync before 3.5.0 contains a logic error in --max-alloc handling that allows a sender or configuration setting --max-alloc=0 to disable allocation sanity checks entirely rather than enforcing a zero-byte cap. Attackers can exploit this flaw to cause the receiver to attempt unbounded memory allocations for file list and data structures, potentially exhausting available memory and causing a denial of service. |
| An issue was discovered in OpenStack Keystone before 29.0.2. POST /v3/credentials did not validate that the caller-supplied project_id for an EC2-type credential matched the project of the authenticating application credential. This allowed an attacker holding an unrestricted application credential for project A to create an EC2 credential targeting project B; a subsequent /v3/ec2tokens exchange would then issue a Keystone token scoped to project B while still carrying the original app_cred_id, enabling cross-project lateral movement within the credential owner's role footprint. |
| The ToASCII and ToUnicode functions incorrectly accept Punycode-encoded labels that decode to an ASCII-only label. For example, ToUnicode("xn--example-.com") incorrectly returns the name "example.com" rather than an error. This behavior can lead to privilege escalation in programs using the idna package. For example, a program which performs privilege checks on the ASCII hostname may reject "example.com" but permit "xn--example-.com". If that program subsequently converts the ASCII hostname to Unicode, it will inadvertently permits access to the Unicode name "example.com". |
| When verifying a certificate chain containing excluded DNS constraints, these constraints are not correctly applied to wildcard DNS SANs which use a different case than the constraint. This only affects validation of otherwise trusted certificate chains, issued by a root CA in the VerifyOptions.Roots CertPool, or in the system certificate pool. |
| url.Parse insufficiently validated the host/authority component and accepted some invalid URLs. |
| jupyterlab is an extensible environment for interactive and reproducible computing, based on the Jupyter Notebook Architecture. From 4.5.0 until 4.5.10 and 4.6.2, in jupyterlab/extensions/manager.py and jupyterlab/extensions/pypi.py, JupyterLab's PyPI extension manager enforces blocked_extensions_uris by comparing requested install names to blocklist entries with custom normalization that is weaker than PyPI package-name canonicalization. An authenticated user can request a PyPI-equivalent spelling such as JupyterLab.Git for a blocklisted package such as jupyterlab-git, and JupyterLab accepts the install request even though pip resolves the variant to the same package. Security impact requires an allowlist or blocklist intended to restrict package installation, the PyPI Extension Manager, and kernels and terminals that are disabled or delegated to remote hosts. The bypass lets an authenticated user install a prohibited extension, defeat integrity restrictions, and affect availability without gaining new read access. This issue is fixed in versions 4.5.10 and 4.6.2. |
| In the Linux kernel, the following vulnerability has been resolved:
net: usb: catc: enable basic endpoint checking
catc_probe() fills three URBs with hardcoded endpoint pipes without
verifying the endpoint descriptors:
- usb_sndbulkpipe(usbdev, 1) and usb_rcvbulkpipe(usbdev, 1) for TX/RX
- usb_rcvintpipe(usbdev, 2) for interrupt status
A malformed USB device can present these endpoints with transfer types
that differ from what the driver assumes.
Add a catc_usb_ep enum for endpoint numbers, replacing magic constants
throughout. Add usb_check_bulk_endpoints() and usb_check_int_endpoints()
calls after usb_set_interface() to verify endpoint types before use,
rejecting devices with mismatched descriptors at probe time.
Similar to
- commit 90b7f2961798 ("net: usb: rtl8150: enable basic endpoint checking")
which fixed the issue in rtl8150. |
| In the Linux kernel, the following vulnerability has been resolved:
media: v4l2-ctrls: validate HEVC active reference counts
HEVC slice parameters are shared stateless V4L2 controls, but the common
validation path does not verify the active L0/L1 reference counts before
driver-specific code consumes them.
The original report came from Cedrus, but the active count bounds are
not Cedrus-specific. Validate them in the common HEVC slice control path
so stateless HEVC drivers get the same basic guarantees as soon as the
control is queued.
Do not reject ref_idx_l0/ref_idx_l1 entries here. Existing userspace may
use out-of-range sentinel values such as 0xff for missing references, and
some hardware can use that information for concealment. Keep this common
check limited to the active reference counts. |
| Admidio is an open-source user management solution. Version 5.0.9 added a missing `isAdministratorInventory()` gate to `case 'item_delete':` in `modules/inventory.php`. The same fix was not applied to the sibling `case 'field_delete':` handler, which destroys an entire inventory field definition, cascading to every `adm_inventory_item_data` row that referenced that field and every `adm_inventory_field_options` entry. The handler validates only a session-bound CSRF token; there is no `isAdministratorInventory()` check at the controller level, and `Admidio\Inventory\Entity\ItemField::delete()` does not enforce one at the entity level either (unlike its sibling `ItemField::save()`, which does check `$gCurrentUser->isAdministrator()`). Any user who can log in to the site can permanently destroy a non-system inventory field by sending one POST. Version 5.0.10 provides an updated fix. |
| Loofah is a general library for manipulating and transforming HTML/XML documents and fragments, built on top of Nokogiri. From 2.25.0 until 2.25.2, Loofah::HTML5::Scrub.allowed_uri? does not reject javascript: URIs whose scheme is split or prefixed with the HTML5 named whitespace character references 	 or 
. CGI.unescapeHTML leaves those references intact, so allowed_uri? reports the URL safe even though a browser decodes and strips the tab or line feed and executes the resulting javascript: URL. This issue affects only callers that pass HTML-encoded strings directly to allowed_uri?; Loofah's default sanitize() path is not affected. This issue is fixed in version 2.25.2. |
| Netty is a network application framework for development of protocol servers and clients. Prior to versions 4.1.135.Final and 4.2.15.Final, the HAProxy PROXY protocol v2 codec in netty leaks native or heap memory on every connection when a client sends a syntactically valid header containing nested `PP2_TYPE_SSL` TLVs (type-length-value records) at depth two or greater. The leak occurs on the successful parse path — no exception is thrown, the message fires downstream, the decoder removes itself, and the application releases the `HAProxyMessage` normally. Yet the underlying cumulation buffer (a pooled, potentially direct `ByteBuf` allocated by the channel) remains permanently pinned. Versions 4.1.135.Final and 4.2.15.Final patch the issue. |
| Netty is a network application framework for development of protocol servers and clients. In netty-handler prior to versions 4.1.135.Final and 4.2.15.Final, an attacker can bypass IPv6 subnet rules due to an incorrect masking operation in IpSubnetFilterRule.compareTo(). Valid public IP addresses can bypass the restrictions. Versions 4.1.135.Final and 4.2.15.Final patch the issue. |
| Netty is an asynchronous, event-driven network application framework. Prior to 4.2.13.Final and 4.1.133.Final, Netty's DNS codec does not enforce RFC 1035 domain name constraints during either encoding or decoding. This creates a bidirectional attack surface: malicious DNS responses can exploit the decoder, and user-influenced hostnames can exploit the encoder. This vulnerability is fixed in 4.2.13.Final and 4.1.133.Final. |
| The RSA and DSA public key parsers did not enforce size limits on key parameters. A crafted public key with an excessively large modulus or DSA parameter could cause several minutes of CPU consumption during signature verification. This could be triggered by unauthenticated clients during public key authentication. RSA moduli are now limited to 8192 bits, and DSA parameters are validated per FIPS 186-2. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/imagination: Fit paired fragment job in the correct CCCB
For geometry jobs with a paired fragment job, at the moment, the
DRM scheduler's prepare_job() callback:
- checks for internal (driver) dependencies for the geometry job;
- calls into pvr_queue_get_paired_frag_job_dep() to check for external
dependencies for the fragment job (the two jobs are submitted together
but the common scheduler code doesn't know about it, so this needs to
be done at this point in time);
- calls into the prepare_job() callback again, but for the fragment job,
to check its internal dependencies as well, passing the fragment job's
drm_sched_job and the geometry job's drm_sched_entity / pvr_queue.
The problem with the last step is that pvr_queue_prepare_job() doesn't
always take the mismatched fragment job and geometry queue into account,
in particular when checking whether there is space for the fragment
command to be submitted, so the code ends up checking for space in the
geometry (i.e. wrong) CCCB.
The rest of the nested prepare_job() callback happens to work fine at
the moment as the other internal dependencies are not relevant for a
paired fragment job.
Move the initialisation of a paired fragment job's done fence and CCCB
fence to pvr_queue_get_paired_frag_job_dep(), inferring the correct
queue from the fragment job itself.
This fixes cases where prepare_job() wrongly assumed that there was
enough space for a paired fragment job in its own CCCB, unblocking
run_job(), which then returned early without writing the full sequence
of commands to the CCCB.
The above lead to kernel warnings such as the following and potentially
job timeouts (depending on waiters on the missing commands):
[ 552.421075] WARNING: drivers/gpu/drm/imagination/pvr_cccb.c:178 at pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr], CPU#2: kworker/u16:5/63
[ 552.421230] Modules linked in:
[ 552.421592] CPU: 2 UID: 0 PID: 63 Comm: kworker/u16:5 Tainted: G W 7.0.0-rc2-gc5d053e4dccb #39 PREEMPT
[ 552.421625] Tainted: [W]=WARN
[ 552.421637] Hardware name: Texas Instruments AM625 SK (DT)
[ 552.421655] Workqueue: powervr-sched drm_sched_run_job_work [gpu_sched]
[ 552.421744] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 552.421766] pc : pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr]
[ 552.421850] lr : pvr_queue_submit_job_to_cccb+0x57c/0xa74 [powervr]
[ 552.421923] sp : ffff800084c47650
[ 552.421936] x29: ffff800084c47740 x28: 0000000000000df8 x27: ffff800088a77000
[ 552.421979] x26: 0000000000000030 x25: ffff800084c47680 x24: 0000000000001000
[ 552.422017] x23: ffff800084c47820 x22: 1ffff00010988ecc x21: 0000000000000008
[ 552.422055] x20: 0000000000000208 x19: ffff000006ad5a88 x18: 0000000000000000
[ 552.422093] x17: 0000000020020000 x16: 0000000000020000 x15: 0000000000000000
[ 552.422130] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
[ 552.422167] x11: 000000000000f2f2 x10: 00000000f3000000 x9 : 00000000f3f3f3f3
[ 552.422204] x8 : 00000000f2f2f200 x7 : ffff700010988ecc x6 : 0000000000000008
[ 552.422241] x5 : 0000000000000000 x4 : 1ffff0001114ee00 x3 : 0000000000000000
[ 552.422278] x2 : 0000000000000007 x1 : 0000000000000fff x0 : 000000000000002f
[ 552.422316] Call trace:
[ 552.422330] pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] (P)
[ 552.422411] pvr_queue_submit_job_to_cccb+0x57c/0xa74 [powervr]
[ 552.422486] pvr_queue_run_job+0x3a4/0x990 [powervr]
[ 552.422562] drm_sched_run_job_work+0x580/0xd48 [gpu_sched]
[ 552.422623] process_one_work+0x520/0x1288
[ 552.422657] worker_thread+0x3f0/0xb3c
[ 552.422679] kthread+0x334/0x3d8
[ 552.422706] ret_from_fork+0x10/0x20 |
| CVAT is an open source interactive video and image annotation tool for computer vision. From 2.17.0 until 2.72.0, a user with write access to a CVAT job can submit a batch automatic annotation request to RequestViewSet.create with inconsistent task and job IDs, and because the task ID determines the single active request slot, block automatic annotation for another task whose ID is known. This issue is fixed in version 2.72.0. |
| In the Linux kernel, the following vulnerability has been resolved:
sched_ext: Don't warn on core-sched forced idle in put_prev_task_scx()
put_prev_task_scx() warns when a runnable task drops to a lower sched_class
without SCX_OPS_ENQ_LAST, on the assumption that balance_one() would have
kept it running. Core scheduling breaks that: a forced-idle SMT sibling
reschedules through the core_pick fast path in pick_next_task(), which skips
pick_task_scx() and thus balance_one(), so a runnable task can drop to idle
with ENQ_LAST unset.
Gate the warning on sched_cpu_cookie_match(): a cookie mismatch means core
scheduling forced the idle, while a match (or core scheduling off) still
catches a genuine missing-ENQ_LAST drop. |
