Export limit exceeded: 40819 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (40819 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-53100 | 1 Linux | 1 Linux Kernel | 2026-06-25 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: fix deadlock in remain-on-channel mt76_remain_on_channel() and mt76_roc_complete() call mt76_set_channel() while already holding dev->mutex. Since mt76_set_channel() also acquires dev->mutex, this results in a deadlock. Use __mt76_set_channel() instead of mt76_set_channel(). Add cancel_delayed_work_sync() for mac_work before acquiring the mutex in mt76_remain_on_channel() to prevent a secondary deadlock with the mac_work workqueue. | ||||
| CVE-2026-53073 | 1 Linux | 1 Linux Kernel | 2026-06-25 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_ldisc: Clear HCI_UART_PROTO_INIT on error When hci_register_dev() fails in hci_uart_register_dev() HCI_UART_PROTO_INIT is not cleared before calling hu->proto->close(hu) and setting hu->hdev to NULL. This means incoming UART data will reach the protocol-specific recv handler in hci_uart_tty_receive() after resources are freed. Clear HCI_UART_PROTO_INIT with a write lock before calling hu->proto->close() and setting hu->hdev to NULL. The write lock ensures all active readers have completed and no new reader can enter the protocol recv path before resources are freed. This allows the protocol-specific recv functions to remove the "HCI_UART_REGISTERED" guard without risking a null pointer dereference if hci_register_dev() fails. | ||||
| CVE-2026-53014 | 1 Linux | 1 Linux Kernel | 2026-06-25 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net/sched: act_mirred: fix wrong device for mac_header_xmit check in tcf_blockcast_redir In tcf_blockcast_redir(), when iterating block ports to redirect packets to multiple devices, the mac_header_xmit flag is queried from the wrong device. The loop sends to dev_prev but queries dev_is_mac_header_xmit(dev) — which is the NEXT device in the iteration, not the one being sent to. This causes tcf_mirred_to_dev() to make incorrect decisions about whether to push or pull the MAC header. When the block contains mixed device types (e.g., an ethernet veth and a tunnel device), intermediate devices get the wrong mac_header_xmit flag, leading to skb header corruption. In the worst case, skb_push_rcsum with an incorrect mac_len can exhaust headroom and panic. The last device in the loop is handled correctly (line 365-366 uses dev_is_mac_header_xmit(dev_prev)), confirming this is a copy-paste oversight for the intermediate devices. Fix by using dev_prev instead of dev for the mac_header_xmit query, consistent with the device actually being sent to. | ||||
| CVE-2026-53037 | 1 Linux | 1 Linux Kernel | 2026-06-24 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: HID: usbhid: fix deadlock in hid_post_reset() You can build a USB device that includes a HID component and a storage or UAS component. The components can be reset only together. That means that hid_pre_reset() and hid_post_reset() are in the block IO error handling. Hence no memory allocation used in them may do block IO because the IO can deadlock on the mutex held while resetting a device and calling the interface drivers. Use GFP_NOIO for all allocations in them. | ||||
| CVE-2026-53029 | 1 Linux | 1 Linux Kernel | 2026-06-24 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: prevent uninitialized lcn caused by zero len syzbot reported a uninit-value in ntfs_iomap_begin [1]. Since runs was not touched yet, run_lookup_entry() immediately fails and returns false, which makes the value of "*len" 0. Simultaneously, the new value and err value are also 0, causing the logic in attr_data_get_block_locked() to jump directly to ok, ultimately resulting in *lcn being triggered before it is set [1]. In ntfs_iomap_begin(), the check for a 0 value in clen is moved forward to before updating lcn to avoid this [1]. [1] BUG: KMSAN: uninit-value in ntfs_iomap_begin+0x8c0/0x1460 fs/ntfs3/inode.c:825 ntfs_iomap_begin+0x8c0/0x1460 fs/ntfs3/inode.c:825 iomap_iter+0x9b7/0x1540 fs/iomap/iter.c:110 Local variable lcn created at: ntfs_iomap_begin+0x15d/0x1460 fs/ntfs3/inode.c:786 | ||||
| CVE-2026-7859 | 2 Motors, Wordpress | 2 Motors, Wordpress | 2026-06-24 | 5.3 Medium |
| The Motors WordPress plugin before 1.4.110 does not have proper authorisation and CSRF checks on one of its AJAX actions, allowing unauthenticated attackers to modify arbitrary post metadata, such as the gallery, featured image and, on WooCommerce sites, product prices. | ||||
| CVE-2026-12549 | 3 Gnome, Libsoup, Redhat | 3 Libsoup, Libsoup, Enterprise Linux | 2026-06-24 | 4.8 Medium |
| The fix for CVE-2026-2443 was regressed by a subsequent rework commit that replaced specific overflow checks with a general signed comparison. When a client sends a Range request with a suffix length exceeding the content size, the resulting negative start value is not properly clamped, leading to malformed HTTP 206 responses and log flooding. | ||||
| CVE-2026-57286 | 2 Jenkins, Jenkins Project | 2 Git Parameter, Jenkins Git Parameter Plugin | 2026-06-24 | 4.3 Medium |
| A missing permission check in Jenkins Git Parameter Plugin 462.vdcf3df2ed2ca_ and earlier allows attackers with Item/Read permission to obtain information about the SCM repository used by a job, such as branch names, tag names, and revision metadata. | ||||
| CVE-2026-57291 | 1 Jenkins Project | 1 Jenkins Gitee Plugin | 2026-06-24 | 5.4 Medium |
| Missing permission checks in Jenkins Gitee Plugin 1288.v18b_deb_c9069b_ and earlier allow attackers with Overall/Read permission to connect to an attacker-specified URL using attacker-specified credentials IDs obtained through another method. | ||||
| CVE-2026-57293 | 1 Jenkins Project | 1 Jenkins Gitee Plugin | 2026-06-24 | 4.3 Medium |
| An incorrect permission check in Jenkins Gitee Plugin 1288.v18b_deb_c9069b_ and earlier allows attackers with global Item/Configure permission (while lacking Item/Configure permission on any particular job) to enumerate credentials IDs of credentials stored in Jenkins. | ||||
| CVE-2026-57294 | 2 Jenkins, Jenkins Project | 2 Ec2 Fleet, Jenkins Ec2 Fleet Plugin | 2026-06-24 | 5.4 Medium |
| A missing permission check in Jenkins EC2 Fleet Plugin 4.2.3.539.v8fedff2a_81c3 and earlier allows attackers with Overall/Read permission to connect to an attacker-specified URL using attacker-specified credentials IDs obtained through another method, capturing AWS credentials stored in Jenkins. | ||||
| CVE-2026-57300 | 2 Jenkins, Jenkins Project | 2 Mcp Server, Jenkins Mcp Server Plugin | 2026-06-24 | 4.3 Medium |
| A missing permission check in Jenkins MCP Server Plugin 0.177.v629fdb_2557fe and earlier allows attackers with Item/Read permission to read the Pipeline replay scripts of jobs they can access. | ||||
| CVE-2026-57304 | 2 Jenkins, Jenkins Project | 2 Assembla, Jenkins Assembla Plugin | 2026-06-24 | 5.4 Medium |
| A missing permission check in Jenkins Assembla Plugin 1.4 and earlier allows attackers with Overall/Read permission to connect to an attacker-specified URL using an attacker-specified username and password. | ||||
| CVE-2026-57307 | 2 Jenkins, Jenkins Project | 2 Zowe Zdevops, Jenkins Zowe Zdevops Plugin | 2026-06-24 | 4.2 Medium |
| A missing permission check in Jenkins Zowe zDevOps Plugin 1.1.3.50.ve350c9b_450b_1 and earlier allows attackers with Overall/Read permission to connect to an attacker-specified URL using attacker-specified credentials IDs obtained through another method, capturing credentials stored in Jenkins. | ||||
| CVE-2026-54906 | 2 Ruby-concurrency, Rubyconcurrency | 2 Concurrent-ruby, Concurrent Ruby | 2026-06-24 | 9.8 Critical |
| concurrent-ruby is a modern concurrency tools for Ruby. Prior to 1.3.7, Concurrent::ReadWriteLock#release_write_lock does not verify that the calling thread acquired the write lock. Any thread with access to the lock object can release an active write lock held by another thread. A second writer can then enter its critical section while the first writer is still running. Concurrent::ReadWriteLock#release_read_lock also decrements the shared counter even when no read lock is held. Calling it on a fresh lock changes the counter from 0 to -1, after which normal read acquisition raises Concurrent::ResourceLimitError. This is a synchronization correctness issue in the public Concurrent::ReadWriteLock API. This vulnerability is fixed in 1.3.7. | ||||
| CVE-2026-12044 | 1 Pgadmin | 1 Pgadmin 4 | 2026-06-24 | 8.8 High |
| SQL injection in pgAdmin 4 across every dialog template that renders ``COMMENT ON ... IS '<description>'`` for a user-supplied description field. The Jinja templates for Domains (and their constraints), Foreign Tables, Languages, and Event Triggers, plus the Views OID-lookup query, interpolated the description directly inside a single-quoted SQL literal -- ``'{{ data.description }}'`` -- instead of passing it through the ``qtLiteral`` escape filter. An authenticated pgAdmin user with permission to create or alter the affected object types could submit a description containing an apostrophe, break out of the literal and chain arbitrary SQL. The injected SQL runs under the PostgreSQL role the user is already authenticated as; for a connected role with ``COPY ... TO/FROM PROGRAM`` (typically PostgreSQL superuser), this chains to OS command execution on the PostgreSQL host. The defect does not cross a privilege boundary -- the user already has direct SQL access to that role through pgAdmin's Query Tool -- so the attacker gains no capability beyond what their database role already grants. The marginal impact captures bypass of any application-layer Query Tool gating an operator may have configured. The defect was originally reported against the Domain Dialog ``description`` field; a code-wide audit identified sixteen sites of the same pattern across the templates listed above. The same review also surfaced ten related sinks in the pgstattuple/pgstatindex stats templates -- ``pgstattuple('{{schema}}.{{table}}')`` and the matching pgstatindex shape -- where ``qtIdent`` escapes embedded double quotes inside the identifier but not apostrophes, so a user with CREATE privilege on a schema could plant a table or index named ``foo'bar`` and a later stats viewer would render an unbalanced literal. Fix is layered: 1. Sites: replace every ``'{{ x.description }}'`` with ``{{ x.description|qtLiteral(conn) }}`` (no surrounding quotes -- the filter wraps the value in escaped quotes itself). Plumb ``conn=self.conn`` through every ``render_template`` call that loads one of these templates. Also corrects a ``{ % elif`` Jinja typo in the foreign-table schema diff (dead branch). Rewrite the ten pgstattuple/pgstatindex stats sites to address the relation via OID + ``::oid::regclass`` cast (e.g. ``pgstattuple({{ tid }}::oid::regclass)``), eliminating the embedded literal-call form entirely so that bug-class can no longer recur there. 2. Driver hardening: ``qtLiteral`` (in ``utils/driver/psycopg3/__init__.py``) used to silently return the raw unescaped value when its ``conn`` argument was falsy. It now raises ``ValueError`` -- surfacing the entire bug class going forward. The change immediately uncovered eight latent plumbing bugs (in ``schemas/__init__.py``, ``schemas/functions/__init__.py``, ``schemas/tables/utils.py``, ``foreign_servers/__init__.py``, and seven sites in ``roles/__init__.py``) -- all fixed as part of this patch. The inner ``except`` block that swallowed adapter-level failures and returned the raw value is also removed, so unadaptable inputs raise instead of leaking unescaped values. 3. Regression tests: a per-template behavioural test renders each previously-vulnerable template with an apostrophe-injection payload and asserts the escaped fragment is present and the vulnerable fragment absent; a lint test walks every ``*.sql`` template flagging any ``'{{ ... }}'`` single-quote-wrapped interpolation against an explicit allowlist; unit tests cover the new qtLiteral fail-fast and inner-except raise paths. This issue affects pgAdmin 4: from 1.0 before 9.16. | ||||
| CVE-2026-12050 | 1 Pgadmin | 1 Pgadmin 4 | 2026-06-24 | 4.3 Medium |
| SQL injection in pgAdmin 4's named restore point endpoint (POST /browser/server/restore_point/{gid}/{sid}). The user-supplied 'value' field was interpolated directly into the SQL string with str.format() instead of being passed as a bound parameter, allowing an authenticated pgAdmin user with a connected PostgreSQL session to inject additional statements through that endpoint. The injected SQL executes under the database role the user is already authenticated as. The defect does not cross a privilege boundary -- the user already has direct SQL access to that role through the Query Tool -- so the attacker gains no capability beyond what their database role already grants them. The marginal impact accounts for the fact that the injection path is not the documented SQL-execution interface, so a deployment that gates the Query Tool at the application layer could see SQL executed through a path it did not anticipate. Fix passes the restore point name as a bound parameter and schema-qualifies the function call as pg_catalog.pg_create_restore_point so a non-default search_path on the connection cannot redirect the call to a shadow definition. A regression test asserts the value arrives as a bound parameter and not spliced into the SQL string. This issue affects pgAdmin 4: from 1.0 before 9.16. | ||||
| CVE-2026-12045 | 1 Pgadmin | 1 Pgadmin 4 | 2026-06-24 | 9 Critical |
| Read-only transaction bypass in the pgAdmin 4 AI Assistant allows an attacker who can influence database content that the assistant reads to execute arbitrary SQL with the privileges of the pgAdmin user's database role. The AI Assistant's execute_sql_query tool runs LLM-generated SQL inside a BEGIN TRANSACTION READ ONLY wrapper to prevent data modification. The LLM-supplied query was forwarded to the database driver without restriction to a single statement or to read-only verbs, so a multi-statement payload beginning with COMMIT, END, ROLLBACK, or ABORT terminated the read-only transaction and ran subsequent statements in autocommit mode. The trailing ROLLBACK then had no effect. Delivery is via prompt injection: an attacker who can write content into any object the AI Assistant may inspect (a row, a column value, a comment) can cause the LLM to emit the multi-statement payload as a tool call. With ordinary write privileges on the pgAdmin user's role the attacker can perform unauthorised data modification. When the pgAdmin user's role is a PostgreSQL superuser or holds pg_execute_server_program, the chain extends to remote code execution on the database server host via COPY ... TO PROGRAM. Fix validates the LLM-supplied query up front: it must parse to exactly one non-empty / non-comment statement whose leading real token (after stripping whitespace, comments, and punctuation) is one of SELECT, WITH, EXPLAIN, SHOW, VALUES, or TABLE. Transaction-control verbs, DML, DDL, CALL, COPY, DO, SET/RESET, and everything else are rejected before any database work happens. PostgreSQL's READ ONLY mode continues to backstop data-modifying CTEs, EXPLAIN ANALYZE on writes, and volatile side effects. This issue affects pgAdmin 4: from 9.13 before 9.16. | ||||
| CVE-2026-10779 | 2 Techlabpro1, Wordpress | 2 Classified Listing – Ai-powered Classified Ads & Business Directory Plugin, Wordpress | 2026-06-24 | 4.3 Medium |
| The Classified Listing – Classified ads & Business Directory plugin for WordPress is vulnerable to Missing Authorization in all versions up to, and including, 5.4.2. This is due to a missing capability/ownership check on the gallery_image_update_as_feature AJAX handler (action: rtcl_fb_gallery_image_update_as_feature), which accepts a user-supplied listing ID and attachment ID and sets the featured image of a listing while only validating a nonce that is exposed to any logged-in user on the frontend listing-submission form. This makes it possible for authenticated attackers, with Subscriber-level access and above, to change the featured image of arbitrary listings they do not own. | ||||
| CVE-2026-10034 | 2 Legalweb, Wordpress | 2 Wp Dsgvo Tools, Wordpress | 2026-06-24 | 5.3 Medium |
| The WP DSGVO Tools (GDPR) plugin for WordPress is vulnerable to authorization bypass in all versions up to, and including, 3.1.39. This is due to the plugin not properly verifying that a user is authorized to perform an action. This makes it possible for unauthenticated attackers to supply an arbitrary victim email address and trigger immediate SAR processing via the process_now and is_ajax parameters, receiving tokenized download links (zip_link, pdf_link) in the HTTP response that expose the victim's personal data — including WordPress account details, comment author names, email addresses, IP addresses, and comment content — without any proof of ownership. The nonce used for the CSRF check is publicly rendered by the SAR shortcode form and is shared across all anonymous visitors, meaning any unauthenticated attacker can trivially obtain a valid nonce and bypass this gate entirely. | ||||