CVE-2022-50518
In the Linux kernel, the following vulnerability has been resolved: parisc: Fix locking in pdc_iodc_print() firmware call Utilize pdc_lock
CVSS
7.8
High
EPSS
0.1%
p3
KEV
—
Exploit Today
1
0-100
Published: Oct 7, 2025 · Last modified: Aug 4, 2026 · CWE-667
0.1%EPSS · 30 days0.1%
2026-09-282026-10-26
In the Linux kernel, the following vulnerability has been resolved: parisc: Fix locking in pdc_iodc_print() firmware call Utilize pdc_lock spinlock to protect parallel modifications of the iodc_dbuf[] buffer, check length to prevent buffer overflow of iodc_dbuf[], drop the iodc_retbuf[] buffer and fix some wrong indentings.
CVECVSSEPSSKEVRExploitTitleMod.
CVE-2026-1061747.5 HIG—
——0A improper locking vulnerability in Fortinet FortiOS 8.0.0, FortiOS 7.6.4 through 7.6.6 may allow an unauthenticated attacker with network access to the device to cause a denial of service of the HTTPS management interface via crafted HTTP requests.2hCVE-2026-110803—20.1%
——6VaadinService.requestEnd() in Vaadin Framework 8 locks the session and then reads the v-uiId request parameter outside the block that releases the lock. A request carrying a non-numeric v-uiId makes Integer.parseInt throw while the session lock is held, so the lock is never released and the container thread returns to its pool still owning it. Every later request to that session then blocks forever in VaadinService.lockSession(), and repeating the request exhausts the thread pool and takes the application down. No authentication is required: a session cookie, which any client obtains with a single request, is enough. Vaadin 10 and later are not affected, because Flow releases the lock in a finally block and does not read that parameter there, and Vaadin Framework 7 is not affected either.
Users of affected versions should apply the following mitigation or upgrade. Releases that have fixed this issue include:
Product version
Vaadin Framework 8.16.0 - 8.32.1
Mitigation
Upgrade to 8.32.2
Vaadin Framework 7 and Vaadin 10 and later do not carry this behaviour and need no upgrade for this issue.
Artifacts
Maven coordinates / Vulnerable versions / Fixed version
com.vaadin:vaadin-server / 8.16.0 - 8.32.1 / >=8.32.2
com.vaadin:vaadin-server-mpr-jakarta / 8.18.0 - 8.32.1 / >=8.32.25dCVE-2026-111879—7.1%
——2DBI versions before 1.656 for Perl hang on a later open of a DBD::DBM table because a failed open_data does not release the table's lock.
open_data creates the table's lock file and takes an exclusive flock on it for a CREATE, before the checks that can croak: a dbm_mldbm value that is not a module name, a failing tie, or a missing data file. The croak unwinds before the table object is blessed, so nothing releases the lock, and the meta data holding the open descriptor stays cached on the database handle.
The dbm_mldbm and dbm_type values come from the DSN or the connect attributes, so a caller that chooses the serializer or the storage backend can trigger the failure.
The flock has no timeout, so a later open of that table (even through a separate database handle) blocks for as long as the handle holding the stale lock lives, in the same process or any other.7dCVE-2026-1076745.1 MED0.0%
——0IBM i 7.3, 7.4, 7.5, and 7.6 is vulnerable to a denial of service to Digital Certificate Manager (DCM) for System TLS using applications attempting to create secure network connections. A bad actor could use this to prevent a service from starting or cause it to fallback to non-secure connections.4dCVE-2026-1036707.5 HIG11.9%
——4When a Gitea Actions run was inserted, older runs in the same workflow-level concurrency group were cancelled without checking whether the new run still needed approval. Because fork pull request runs are inserted under the base repository, a user who can open a pull request from a fork could cancel trusted in-progress runs that share a concurrency group with `cancel-in-progress` enabled, without approval and without running any code. On self-hosted runners this can interrupt deployments and leave partial state behind.12dCVE-2026-1051136.5 MED14.9%
——4Nezha Dashboard from 1.8.0 before 2.3.13 contains an improper locking vulnerability where a non-deferred mutex unlock leaks on a nil-map panic path. Any authenticated non-admin member can issue four notification API calls to permanently deadlock the alerting subsystem, then exhaust memory with blocking requests.22d