Export limit exceeded: 47581 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (47581 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2017-20280 | 1 Myportfolio | 1 Myportfolio | 2026-08-19 | 8.2 High |
| Joomla Component Myportfolio 3.0.2 contains an SQL injection vulnerability that allows unauthenticated attackers to manipulate database queries by injecting SQL code through the pid parameter. Attackers can send GET requests to index.php with malicious pid values in the task=project&view=grid endpoint to extract sensitive database information. | ||||
| CVE-2017-20282 | 1 Soft-php | 1 Jcart For Opencart | 2026-08-19 | 8.2 High |
| Joomla! Component jCart for OpenCart 2.0 contains an SQL injection vulnerability that allows unauthenticated attackers to manipulate database queries by injecting SQL code through the product_id parameter. Attackers can send GET requests to index.php with the option=com_jcart&route=product/product parameters and malicious product_id values to extract sensitive database information. | ||||
| CVE-2026-76223 | 1 Arcadedata | 1 Arcadedb | 2026-08-19 | 7.1 High |
| ArcadeDB (com.arcadedb) versions 26.7.3 and earlier fail to enforce the UPDATE_SCHEMA permission check when a DEFINE FUNCTION statement targets an already-existing function library. A user with only database access can add or overwrite SQL or Cypher functions in an existing library and persist the change, enabling tampering with admin-defined function logic. The issue is fixed in 26.8.1. (JavaScript functions still trigger the UPDATE_SECURITY check and are not affected.) | ||||
| CVE-2019-25751 | 1 Cmsjunkie | 2 Classifiedsmanager, J-classifiedsmanager | 2026-08-19 | 8.2 High |
| Joomla Component J-ClassifiedsManager 3.0.5 contains an SQL injection vulnerability that allows unauthenticated attackers to execute arbitrary SQL queries by injecting malicious code through POST parameters. Attackers can submit crafted SQL payloads in the categorySearch, adType, and citySearch parameters to the displayads component to extract sensitive database information including usernames, databases, and version details. | ||||
| CVE-2026-74472 | 1 Linux | 1 Linux Kernel | 2026-08-19 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: ublk: reset kernel-owned dev_info fields in ublk_ctrl_add_dev() ublk_ctrl_add_dev() memcpy()s the userspace ublksrv_ctrl_dev_info into ub->dev_info and then fixes up the fields the driver owns, but misses ->state and ->ublksrv_pid. A device added with ->state = UBLK_S_DEV_LIVE passes the "->state != UBLK_S_DEV_DEAD" test that ublk_stop_dev_unlocked() uses as its proxy for "a disk is attached", while ->ub_disk is still NULL, so DEL_DEV right after ADD_DEV oopses in del_gendisk(). UBLK_S_DEV_QUIESCED plus UBLK_F_USER_RECOVERY dies one step earlier, in ublk_force_abort_dev(). A poisoned ->state also gets START_USER_RECOVERY and the char device read/write path onto a device that was never started, and wedges START_DEV at -EEXIST. A poisoned ->ublksrv_pid just makes GET_DEV_INFO report an unrelated task as the ublk server. Reset both after the memcpy(), as ublk_detach_disk() does. Userspace only ever reads these back, so correcting them silently breaks nothing. ADD_DEV has copied ->state in unsanitized since ublk was merged, but back then it was harmless: the gendisk was allocated during ADD_DEV, and both teardown and the START_DEV -EEXIST check keyed off disk_live() rather than ->state. The oops became reachable once the disk allocation moved to START_DEV and those checks switched to ->state. | ||||
| CVE-2026-65675 | 1 Microsoft | 3 Github Copilot Chat, Visual Studio Code, Visual Studio Code Copilot Chat Extension | 2026-08-19 | 7.1 High |
| No cwe for this issue in Visual Studio Code CoPilot Chat Extension allows an unauthorized attacker to bypass a security feature over a network. | ||||
| CVE-2026-18779 | 2 Truebooker, Wordpress | 2 Truebooker, Wordpress | 2026-08-19 | 5.3 Medium |
| The TrueBooker WordPress plugin before 1.2.7 does not have proper authorisation checks in one of its AJAX actions, allowing unauthenticated users to delete arbitrary appointment records along with their associated booking items and payment records. | ||||
| CVE-2026-19629 | 1 Tenable | 1 Security Center | 2026-08-19 | 8.1 High |
| A privilege escalation vulnerability exists in Tenable Security Center that allows a user with "Security Manager" role and "manage user" permission on a single group to modify users belonging to other groups. This bypasses the intended access control restrictions and enables unauthorized cross-group user management. | ||||
| CVE-2026-21076 | 2 Samsung, Samsung Mobile | 2 Health, Samsung Health | 2026-08-19 | 5.5 Medium |
| Incorrect authorization in Samsung Health prior to version 7.0.0 allows local attackers to access sensitive information. | ||||
| CVE-2026-19631 | 1 Tenable | 1 Security Center | 2026-08-19 | 4.9 Medium |
| A SQL injection vulnerability exists in Security Center that could allow an authenticated administrator to execute arbitrary SQL queries, potentially resulting in unauthorized access to sensitive data, including credentials. | ||||
| CVE-2026-74973 | 1 Mozilla | 2 Firefox, Thunderbird | 2026-08-19 | 4.2 Medium |
| Race condition, use-after-free in the Graphics component. This vulnerability was fixed in Firefox 154, Firefox ESR 115.39, Firefox ESR 140.14, Firefox ESR 153.1, Thunderbird 154, Thunderbird 140.14, and Thunderbird 153.1. | ||||
| CVE-2026-20483 | 2 Mediatek, Mediatek, Inc. | 71 Mt6739, Mt6739 Firmware, Mt6761 and 68 more | 2026-08-19 | 7.7 High |
| In Telephony, there is a possible escalation of privilege due to a missing permission check. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS11087526; Issue ID: MSV-8243. | ||||
| CVE-2026-19680 | 1 Tenable | 1 Security Center | 2026-08-19 | 7.1 High |
| A SQL injection vulnerability exists in Security Center that could allow an attacker to access unauthorized data from the application's database. | ||||
| CVE-2026-15423 | 1 Gitlab | 1 Gitlab | 2026-08-19 | 8.5 High |
| GitLab has remediated an issue in GitLab CE/EE affecting all versions from 19.0 before 19.0.6, 19.1 before 19.1.4, and 19.2 before 19.2.2 that under certain conditions could have allowed an authenticated user with developer-role permissions to execute CI/CD pipelines on a protected branch without the required push permissions due to improper authorization in pipeline reference validation. | ||||
| CVE-2026-4879 | 1 Gitlab | 1 Gitlab | 2026-08-19 | 4.3 Medium |
| GitLab has remediated an issue in GitLab EE affecting all versions from 16.0 before 19.0.6, 19.1 before 19.1.4, and 19.2 before 19.2.2 that under certain conditions could have allowed an authenticated user with developer-role permissions to view external status check configuration restricted to higher-privileged roles due to missing authorization on a merge request API endpoint. | ||||
| CVE-2026-6821 | 1 Gitlab | 1 Gitlab | 2026-08-19 | 4.3 Medium |
| GitLab has remediated an issue in GitLab EE affecting all versions from 12.0 before 19.0.6, 19.1 before 19.1.4, and 19.2 before 19.2.2 that under certain conditions could have allowed an authenticated user to bypass IP-based access restrictions and read limited merge request information from a private project due to missing authorization checks in a merge requests API endpoint. | ||||
| CVE-2026-74555 | 1 Linux | 1 Linux Kernel | 2026-08-19 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: scsi: libsas: Fix HA resume deadlock and hisi_sas disk-wake race Commit fbefe22811c3 ("scsi: libsas: Don't always drain event workqueue for HA resume") introduced sas_resume_ha_no_sync() to avoid a deadlock: the PHYE_RESUME_TIMEOUT handler, running on the HA event workqueue, calls sas_deform_port() -> sas_destruct_devices(), which removes SCSI devices and waits for the host to become runtime-active. But the host cannot resume until sas_resume_ha() -> sas_drain_work() returns, and the drain is blocked on that very handler. However skipping the drain reintroduces a race: hisi_sas returns from resume before all PHY UP work and libsas discovery work finish. The controller may then autosuspend while disks are still waking up. The disks issue IO to a suspended controller, the IO fails, and the disks get disabled. Fix the deadlock at its source by moving the PHYE_RESUME_TIMEOUT notification to after sas_drain_work(). By then the host resume is about to complete, so device removal through device_link no longer blocks on the resume and the cycle is broken. With the deadlock gone, restore sas_resume_ha() (the draining variant) in hisi_sas and remove sas_resume_ha_no_sync(). The reorder is safe for the other libsas consumers (isci, pm8001, aic94xx, mvsas). During suspend, sas_suspend_devices() calls sas_notify_lldd_dev_gone() for each device, which sets dev->lldd_dev to NULL. When scsi_unblock_requests re-enables I/O in resume, any I/O to a timed-out phy's disk is immediately rejected by the LLDD before reaching hardware: isci returns SAS_DEVICE_UNKNOWN (mapped to DID_BAD_TARGET), and pm8001 returns SAS_PHY_DOWN (mapped to DID_NO_CONNECT). Both complete directly via scsi_done() without entering SCSI EH. This is identical in both the old and new ordering since lldd_dev_gone runs during suspend, before resume. The reorder only affects when the PHYE_RESUME_TIMEOUT handler runs (synchronized by sas_drain_work() vs. asynchronous after resume returns), not whether I/O can reach the device. aic94xx and mvsas do not register any PM ops and never reach this code path. | ||||
| CVE-2026-68370 | 1 Linux | 1 Linux Kernel | 2026-08-19 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: usb: gadget: dummy_hcd: prevent fifo_req reuse during giveback dummy_hcd embeds a single shared usb_request (dum->fifo_req) that the "emulated single-request FIFO" fast-path in dummy_queue() reuses for small IN transfers: it copies the caller's request into it (req->req = *_req) and queues it, treating list_empty(&fifo_req.queue) as "the slot is free". The completion side (dummy_timer/transfer/nuke/dummy_dequeue) follows the standard pattern: list_del_init(&req->queue) unlinks the request, then the lock is dropped and usb_gadget_giveback_request() invokes req->complete(). But list_del_init() makes fifo_req.queue look empty *before* the completion callback returns, so a concurrent dummy_queue() on another CPU sees the slot as free, reuses fifo_req and runs req->req = *_req -- overwriting req->complete while dummy_timer is mid-calling it. The indirect call then jumps to a clobbered pointer, causing a general protection fault / page fault in dummy_timer (syzkaller extid faf3a6cf579fc65591ca). The clobbering write is an in-bounds memcpy on a live shared object, so KASAN cannot flag it. Add a fifo_req_busy bit covering the shared request's whole lifetime: set it in dummy_queue() when the FIFO fast-path takes fifo_req (making it the fast-path guard, replacing the list_empty(&fifo_req.queue) test), and clear it after the completion callback has returned, via a dummy_giveback() helper used at all four gadget-request giveback sites. The shared slot can no longer be reused until its completion callback has finished. | ||||
| CVE-2026-68369 | 1 Linux | 1 Linux Kernel | 2026-08-19 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: usb: gadget: printer: fix infinite loop in printer_read() printer_read() uses the same variable for the requested copy size and the number of bytes actually copied to user space. copy_to_user() returns the number of bytes not copied, so when it fails to copy anything, the computed copied length becomes zero. In that case len, buf, current_rx_bytes and current_rx_buf are left unchanged. If RX data is available and the user buffer remains unwritable, the read loop can repeat indefinitely. Track the copied length separately and return -EFAULT, or the number of bytes already copied, if an iteration makes no progress. | ||||
| CVE-2026-68362 | 1 Linux | 1 Linux Kernel | 2026-08-19 | 4.7 Medium |
| In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix NULL pointer dereference in ath11k_hal_srng_access_begin In ATH11K_QMI_EVENT_FW_READY, ATH11K_FLAG_REGISTERED is set unconditionally even when ath11k_core_qmi_firmware_ready() fails. This leaves the driver in an inconsistent state where initialization is considered complete although the firmware ready handling did not finish successfully. During the subsequent SSR, the driver enters the restart path based on this incorrect state and dereferences uninitialized srng members, resulting in a NULL pointer dereference. Call trace: ath11k_hal_srng_access_begin+0xc/0x60 [ath11k] (P) ath11k_ce_cleanup_pipes+0x17c/0x180 [ath11k] ath11k_core_restart+0x40/0x168 [ath11k] Fix this by: - skipping firmware_ready if ATH11K_FLAG_REGISTERED is already set - setting ATH11K_FLAG_REGISTERED only when firmware_ready succeeds - setting ATH11K_FLAG_QMI_FAIL and aborting the FW_READY handling on error Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.2.0.c2-00204-QCAMSLSWPLZ-1 | ||||