Vulnerabilities
All
My stack
Known exploited
Public exploit
Critical (9+)
Likely exploited (EPSS ≥ 50%)
Changed, 24 h
New, 24 h
Sort:
risk
modified
published
CVSS
EPSS
| CVE | CVSS | EPSS | Vendor, product | Description | Modified |
|---|---|---|---|---|---|
| CVE-2026-57949 | 7.1 high | 0.00% | no CPE yet | ruoyi-vue-pro through 2026.05, fixed in commit c779a47, contains a missing authorization vulnerability in the CRM module's GET /admin-api/crm/follow-up-record/get endpoint that allows authenticated users to read any follow-up record by iterating sequential numeric IDs. Attackers can exploit this by sending requests with arbitrary ID parameters to access other users' follow-up notes, file attachments, scheduling information, and business entity references without proper authorization checks. | Sun 25 Oct |
| CVE-2026-58410 | 7.1 high | 0.00% | no CPE yet | ChurchCRM is an open-source church management system. Prior to version 7.4.0, there was an authorization flaw in the family-scoped endpoints which allowed low-privileged users to read and modify other families’ records. An authenticated non-admin user with EditSelf access can supply another family’s `familyId` and access records outside their own family scope. The backend trusts the attacker-controlled `familyId` and loads the corresponding family entity by ID without verifying that the requested family belongs to the current user. If the same user also has Notes permission, they can create notes on another family’s record. This breaks the intended EditSelf scope and allows access to unrelated congregation records. This issue has been fixed in version 7.4.0. | Sat 24 Oct |
| CVE-2026-21577 | 7.1 high | 0.00% | atlassian, confluence_data_center | This High severity DoS (Denial of Service) vulnerability was introduced in versions 9.0.1, 9.1.0, 9.2.0, 9.3.1, 9.4.0, 9.5.1, 10.0.2, 10.1.0 and 10.2.0 of Confluence Data Center. This DoS (Denial of Service) vulnerability, with a CVSS Score of 7.1, allows an authenticated attacker to cause a resource to be unavailable for its intended users by temporarily or indefinitely disrupting services of a host connected to a network. Atlassian recommends that Confluence Data Center customers upgrade to latest version, if you are unable to do so, upgrade your instance to one of the specified supported fixed versions: Confluence Data Center 9.2: Upgrade to a release greater than or equal to 9.2.17 Confluence Data Center 10.2: Upgrade to a release greater than or equal to 10.2.7 See the release notes ([https://confluence.atlassian.com/doc/confluence-release-notes-327.html]). You can download the latest version of Confluence Data Center from the download center ([https://www.atlassian.com/software/confluence/download-archives]). This vulnerability was reported via our Penetration Testing program. | Sat 24 Oct |
| CVE-2026-115478 | 7.1 high | 0.00% | no CPE yet | obsidian-tc is a governed, agent-ready Model Context Protocol server for Obsidian vaults. From 1.0.1 until 1.31.4, `create_entity`, `link_entities`, `rename_entity`, `unlink_entities` and `delete_entity` regenerate memory notes from SQLite at the computed `memory/<type>/<name>.md` path without reliably preserving note ownership or the consistency of a failed lifecycle operation. During shared materialization, a hand-authored note or an orphan left by a different entity whose name sanitized to the same path could have its entire body overwritten on the next write naming that type and name, with non-owned frontmatter preserved. `rename_entity` also seeded the destination path with a direct atomic write without validating ownership and could overwrite a foreign note there. Separately, several tools mutated SQLite before fallible filesystem work: `create_entity` and `link_entities` inserted the row or relation before materialization; `rename_entity` updated the entity, including a retired status, before updating its note; `unlink_entities` removed a relation before rematerializing the source note; and `delete_entity`'s cascade removed the target and its relations before rematerializing neighbouring notes. A later filesystem failure could therefore leave a row or relation changed and the memory graph inconsistent with the notes on disk even when the operation failed. An authorized caller with the required memory-tool permissions could, without intending to, destroy the body of a vault note outside the entity being written; `delete_entity` additionally requires its deletion permission and destructive confirmation, which this memory flaw does not bypass. Snapshots-before-write through `restore_note` mitigate the overwrite only where snapshots are enabled and the note had previously been written through obsidian-tc. This issue is fixed in version 1.31.4. | Fri 23 Oct |
| CVE-2026-114396 | 7.1 high | 0.00% | no CPE yet | Trudesk through 1.2.11 contains a server-side JavaScript injection vulnerability that allows authenticated users to inject code into a MongoDB $where clause via the search parameter. Attackers can close the regular expression in GET /api/v1/tickets/search to loop mongod for denial of service or leak full ticket documents including internal notes. | 22 Oct |
| CVE-2026-90131 | 7.1 high | 0.00% | no CPE yet | In the Linux kernel, the following vulnerability has been resolved: ntfs: serialize resident iomap reads with mrec_lock ntfs_read_iomap_begin_resident() walks the MFT record through ntfs_attr_lookup() -> ntfs_attr_find() without taking ni->mrec_lock, while ntfs_attr_record_resize(), ntfs_make_room_for_attr() and ntfs_resident_attr_record_add() memmove() the same base_ni->mrec buffer under that lock. map_mft_record() only takes a reference and does not serialize, so the reader can observe torn attribute length and offset fields while a writer is relocating the records. KCSAN reports the race between the mmap read fault path and both link() and unlink(): BUG: KCSAN: data-race in ntfs_attr_find / ntfs_attr_record_resize write to 0xffff888100af1018 of 4 bytes by task 96 on cpu 1: ntfs_attr_record_resize+0xd2/0x130 ntfs_attr_record_rm+0xad/0x530 ntfs_delete+0x224/0x640 ntfs_unlink+0x14d/0x280 vfs_unlink+0x157/0x520 read to 0xffff888100af1018 of 4 bytes by task 95 on cpu 0: ntfs_attr_find+0x104/0x5b0 ntfs_attr_lookup+0x39c/0x10c0 ntfs_read_iomap_begin_resident+0xc6/0x230 ntfs_read_iomap_begin+0x5d/0xa0 iomap_iter+0x2e2/0x6e0 iomap_read_folio+0x147/0x2a0 ntfs_read_folio+0x108/0x170 filemap_read_folio+0x35/0x100 filemap_fault+0x993/0x1000 value changed: 0x00000250 -> 0x000001f0 The address is mrec + 0x18, i.e. mft_record.bytes_in_use, and the change is the 96 bytes of one $FILE_NAME attribute being removed. Keep base_ni->mrec_lock from the resident read iomap lookup through iomap_end(). This protects both the attribute walk and the subsequent copy from iomap->inline_data, which points into the MFT record. The non-resident path is left alone: ntfs_lookup() already holds the directory inode's mrec_lock when it reads an index folio through read_mapping_folio(), and taking the lock in the shared wrapper deadlocks there with recursive locking on mrec_lock. The comment above the read_mapping_folio() call in fs/ntfs/dir.c notes the same hazard. The seek path uses the same lookup helper but does not dereference iomap->inline_data. Release the lock before returning from that path, whereas the regular read path records base_ni in iomap->private and releases the lock from its iomap_end() callback. Tested with a reproducer that faults in a 16-byte resident file while another thread runs link()/unlink() on it. Before: 40 KCSAN reports in about one second. After: no reports in 180 seconds over 206,090 read iterations and 423,540 link/unlink cycles. A PROVE_LOCKING build shows no lockdep splat with the same reproducer running for 60 seconds. | 19 Oct |
| CVE-2026-55381 | 7.1 high | 0.00% | no CPE yet | InvoiceShelf is an open-source web & mobile app that helps track expenses, payments and create professional invoices and estimates. Prior to version 2.4.0, POST /api/v1/estimates/{estimate}/convert-to-invoice in ConvertEstimateController authorizes only the caller's create-invoice ability and does not authorize access to the route-bound Estimate. Because route-model binding can resolve an estimate from any company, an authenticated user with create-invoice ability can copy another company's line items, prices, totals, taxes, notes, currency, and customer data into an invoice in the attacker's company. The victim company's configured conversion action reaches checkForEstimateConvertAction and can also change or delete the original estimate. This issue is fixed in version 2.4.0. | 15 Oct |
| CVE-2024-50164 | 7.1 high | 0.00% | linux, linux_kernel | In the Linux kernel, the following vulnerability has been resolved: bpf: Fix overloading of MEM_UNINIT's meaning Lonial reported an issue in the BPF verifier where check_mem_size_reg() has the following code: if (!tnum_is_const(reg->var_off)) /* For unprivileged variable accesses, disable raw * mode so that the program is required to * initialize all the memory that the helper could * just partially fill up. */ meta = NULL; This means that writes are not checked when the register containing the size of the passed buffer has not a fixed size. Through this bug, a BPF program can write to a map which is marked as read-only, for example, .rodata global maps. The problem is that MEM_UNINIT's initial meaning that "the passed buffer to the BPF helper does not need to be initialized" which was added back in commit 435faee1aae9 ("bpf, verifier: add ARG_PTR_TO_RAW_STACK type") got overloaded over time with "the passed buffer is being written to". The problem however is that checks such as the above which were added later via 06c1c049721a ("bpf: allow helpers access to variable memory") set meta to NULL in order force the user to always initialize the passed buffer to the helper. Due to the current double meaning of MEM_UNINIT, this bypasses verifier write checks to the memory (not boundary checks though) and only assumes the latter memory is read instead. Fix this by reverting MEM_UNINIT back to its original meaning, and having MEM_WRITE as an annotation to BPF helpers in order to then trigger the BPF verifier checks for writing to memory. Some notes: check_arg_pair_ok() ensures that for ARG_CONST_SIZE{,_OR_ZERO} we can access fn->arg_type[arg - 1] since it must contain a preceding ARG_PTR_TO_MEM. For check_mem_reg() the meta argument can be removed altogether since we do check both BPF_READ and BPF_WRITE. Same for the equivalent check_kfunc_mem_size_reg(). | 15 Oct |
| CVE-2026-62026 | 7.1 high | 0.00% | no CPE yet | Cross-Site Request Forgery (CSRF) vulnerability in MIGHTYminnow Dashboard Notes dashboard-notes allows Cross Site Request Forgery.This issue affects Dashboard Notes: from n/a through 1.0.3. | 9 Oct |
| CVE-2025-21066 | 7.1 high | 0.00% | samsung, notes | Out-of-bounds read in the SPI decoder in Samsung Notes prior to version 4.4.30.63 allows local attackers to access out-of-bounds memory. | 8 Oct |
| CVE-2025-21067 | 7.1 high | 0.00% | samsung, notes | Out-of-bounds read in the allocation of image buffer in Samsung Notes prior to version 4.4.30.63 allows local attackers to access out-of-bounds memory. | 8 Oct |
| CVE-2025-21068 | 7.1 high | 0.00% | samsung, notes | Out-of-bounds read in the reading of image data in Samsung Notes prior to version 4.4.30.63 allows local attackers to access out-of-bounds memory. | 8 Oct |
| CVE-2025-21069 | 7.1 high | 0.00% | samsung, notes | Out-of-bounds read in the parsing of image data in Samsung Notes prior to version 4.4.30.63 allows local attackers to access out-of-bounds memory. | 8 Oct |
| CVE-2026-116810 | 6.9 medium | 0.00% | no CPE yet | OpenPanel before 3.0.0 contains a missing authorization vulnerability that allows unauthenticated attackers to read any project's annotations by calling the public reference.getChartReferences tRPC procedure. Attackers can send requests with guessable slug-based project IDs to dump cross-tenant annotation titles, descriptions, and dates such as release notes and deploy markers. | Tue 27 Oct |
| CVE-2026-6941 | 6.9 medium | 0.00% | radare, radare2 | radare2 prior to 6.1.4 contains a path traversal vulnerability in its project notes handling that allows attackers to read or write files outside the configured project directory by importing a malicious .zrp archive containing a symlinked notes.txt file. Attackers can craft a .zrp archive with a symlinked notes.txt that bypasses directory confinement checks, allowing note operations to follow the symlink and access arbitrary files outside the dir.projects root directory. | Mon 26 Oct |
| CVE-2026-110875 | 6.9 medium | 0.00% | no CPE yet | AdPlug through 2.4 contains a heap-based buffer overflow in CksmPlayer::update() in src/ksm.cpp that writes past the fixed databuf[2048] array without bounds checking. Attackers can supply a crafted .ksm module whose notes share one time slot to overflow the heap player object, causing memory corruption and denial of service. | Mon 26 Oct |
| CVE-2026-72783 | 6.9 medium | 0.00% | no CPE yet | Craft CMS versions >= 5.0.0-RC1 before 5.10.6 and >= 4.0.0-RC1 before 4.18.2 contain a theoretical path traversal weakness in the ensurePathIsContained function of the Local file system class. The order of operations validates the path before normalization, so normalization could invalidate prior validation assumptions (a desanitization-style issue) and potentially resolve to files outside the intended volume directory. The vendor notes the issue is not directly exploitable and no exploitable scenario has been discovered; the fix is recommended for hardening. | Sat 24 Oct |
| CVE-2026-72808 | 6.9 medium | 0.00% | no CPE yet | SiYuan versions up to and including v3.7.2 (fixed in v3.7.4) contain an information disclosure vulnerability in the /api/asset/getFileAnnotation endpoint, which returns .sya PDF-annotation file content without a publish-access check. Because the endpoint is gated only by CheckAuth (unlike the /assets/* route, which enforces publish access and password), an anonymous reader (when publish authentication is disabled) or any publish RoleReader who knows an asset path can read the private PDF annotations (highlights and notes) of publish-forbidden, password-protected, or unpublished documents. The issue is limited to non-encrypted notebooks; encrypted-box annotations are not exposed. | Sat 24 Oct |
| CVE-2026-77710 | 6.9 medium | 0.00% | no CPE yet | A vulnerability in misp-stix could allow a crafted STIX document to influence security-sensitive MISP attribute metadata during import. The STIX import logic automatically selected between the internal MISP parser and the external STIX parser based on metadata contained in the STIX document itself. For STIX2, the presence of MISP-specific tool labels could cause a document to be classified as originating from MISP; similarly, STIX1 relied on the document title. These classification indicators are fully controlled by the STIX producer and therefore cannot constitute a trusted indication of the document's origin. The accompanying fix explicitly notes that the parser choice was previously based solely on labels or header titles that any producer could write, and introduces an explicit classification parameter allowing callers to override this detection. When STIX2 content was handled as an internal MISP export, attributes contained in an x-misp-object were converted by copying the complete x_misp_attributes dictionary and passing it directly to misp_object.add_attribute(). Consequently, a crafted STIX bundle could supply fields that were not part of the expected STIX-to-MISP round-trip format, including security-sensitive properties such as distribution, sharing_group_id, tags, or other MISP attribute fields. An attacker able to provide a STIX document for import could therefore spoof the markers used to identify MISP-generated content and inject additional attribute properties. This could alter the distribution, sharing restrictions, classification, or semantic metadata of imported attributes, potentially causing information to be shared contrary to the importing organization's policy or influencing downstream processing and automation based on attacker-controlled tags or metadata. The vulnerability results from dynamically assigning externally supplied object properties without restricting them to an expected set of attributes, matching CWE-915. MITRE specifically describes this weakness as accepting externally influenced fields without controlling which object attributes may be modified and recommends an allow-list, which is the approach implemented by the patch. The parser-selection issue additionally corresponds to CWE-807, because an untrusted value was used to make a security-relevant trust/classification decision. The attack is also consistent with CAPEC-153 (Input Data Manipulation), in which an attacker controls the structure or flags of supplied data so that the target selects a different processing path or interprets the content differently than intended. | 16 Oct |
| CVE-2026-42291 | 6.8 medium | 0.00% | no CPE yet | SysReptor is a fully customizable pentest reporting platform. From version 2026.4 to before version 2026.27, the endpoints for reading and creating sharing links for personal notes is not properly authorized. This allows authenticated attackers who obtain the note ID of victim users to list and create sharing links to those users' personal notes. This gives attackers read and write access to notes of other users. This exploit works in both SysReptor Professional and Community. In Community it has, however, no impact because all users have superuser permissions and can list personal notes of other users at /admin/pentests/usernotebookpage/. This issue has been patched in version 2026.27. | Mon 26 Oct |
| CVE-2026-115993 | 6.8 medium | 0.00% | no CPE yet | Stored XSS vulnerability in the “Notes” field of the Checklists in Cervantes version v1.3-beta could allow an attacker to execute arbitrary code in another user's browser with elevated privileges | Mon 26 Oct |
| CVE-2026-111166 | 6.8 medium | 0.00% | no CPE yet | libmikmod through 3.3.15 contains a heap out-of-bounds read vulnerability in the IMF_Load() loader that allows attackers to read beyond allocated memory by supplying a crafted IMF module. Attackers can enable the linear-period header flag and map notes to out-of-range samples, causing noteindex indexing far past the heap allocation and crashing applications that load the file. | 16 Oct |
| CVE-2026-33954 | 6.5 medium | 0.00% | linkace | LinkAce is a self-hosted archive to collect website links. In versions prior to 2.5.3, a private note attached to a non-private link can be disclosed to a different authenticated user via the web interface. The API appears to correctly enforce note visibility, but the web link detail page renders notes without applying equivalent visibility filtering. As a result, an authenticated user who is allowed to view another user's `internal` or `public` link can read that user's `private` notes attached to the link. Version 2.5.3 patches the issue. | Mon 26 Oct |
| CVE-2026-48943 | 6.5 medium | 0.00% | joomlaworks, k2 | K2 ≤ 2.24 contains a mass-assignment defect in the K2 system user plugin `plg_user_k2`. A Registered Joomla user, by including the field `K2UserForm=1` in a standard `com_users` `profile.save` POST, can write arbitrary values into the `notes`, `image`, and `plugins` columns of their own row in the `#__k2_users` table — none of which are exposed by the K2 frontend profile-edit form. | Sun 25 Oct |
| CVE-2026-72554 | 6.5 medium | 0.00% | no CPE yet | A broken access control vulnerability in Ladybird Web Solution Faveo Helpdesk 2.0.3 allows any self-registered customer to read ticket conversations belonging to other customers via the v1 REST API. The API verifies the existence of the requested ticket but not ownership, enabling any authenticated user to access arbitrary ticket threads including internal agent notes containing sensitive information. | Sat 24 Oct |
| CVE-2025-1250 | 6.5 medium | 0.00% | gitlab | An issue has been discovered in GitLab CE/EE affecting all versions from 15.0 before 18.1.6, 18.2 before 18.2.6, and 18.3 before 18.3.2 that could have allowed an authenticated user to stall background job processing by sending specially crafted commit messages, merge request descriptions, or notes. | 19 Oct |
| CVE-2026-46694 | 6.5 medium | 0.00% | no CPE yet | EspoCRM is an open source customer relationship management application. Prior to 9.3.7, a portal user with stream access to a parent record can directly fetch a Note through the portal Note API and read an internal stream note when the note identifier is known. Stream list responses correctly hide notes whose isInternal field is true, but the direct single-Note access check does not enforce that restriction, exposing internal agent content. This issue is fixed in version 9.3.7. | 16 Oct |
| CVE-2025-6016 | 6.5 medium | 0.00% | gitlab | GitLab has remediated an issue in GitLab CE/EE affecting all versions from 9.2 before 18.9.6, 18.10 before 18.10.4, and 18.11 before 18.11.1 that could have allowed an authenticated user to cause denial of service due to insufficient resource allocation limits when retrieving notes under certain conditions. | 14 Oct |
| CVE-2026-86851 | 6.5 medium | 0.00% | no CPE yet | The Livees Checkout WordPress plugin through 7.0.2 does not perform any capability, nonce or order-key check before acting on request parameters on the order confirmation page, allowing unauthenticated users to change the status of arbitrary orders, store arbitrary data and notes on them, and recover their order keys. | 9 Oct |
| CVE-2024-34321 | 6.1 medium | 0.00% | no CPE yet | ProPhoenix Law RMS v2022.2403.3.101 was discovered to contain a reflected cross-site scripting (XSS) vulnerability via the PageTitle/Notes parameter in the Notes.aspx endpoint. | Tue 27 Oct |
| CVE-2025-60934 | 6.1 medium | 0.00% | no CPE yet | Multiple stored cross-site scripting (XSS) vulnerabilities in the index.php component of HR Performance Solutions Performance Pro v3.19.17 allows attackers to execute arbitrary web scripts or HTML via a crafted payload injected into the Employee Notes, title, or description parameters. The patched version is PP-Release-6.3.2.0. | Tue 27 Oct |
| CVE-2026-40265 | 5.9 medium | 0.00% | no CPE yet | Note Mark is an open-source note-taking application. In versions 0.19.1 and prior, the asset download endpoint at /api/notes/{noteID}/assets/{assetID} is registered without authentication middleware, and the backend query does not verify ownership or book visibility. An unauthenticated user who knows a valid note ID and asset ID can retrieve the full contents of private note assets without authentication, regardless of whether the associated book is public or private. This issue has been fixed in version 0.19.2. | Mon 26 Oct |
| CVE-2025-60136 | 5.9 medium | 0.00% | no CPE yet | Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') vulnerability in cartpauj User Notes user-notes allows Stored XSS.This issue affects User Notes: from n/a through <= 1.0.2. | 11 Oct |
| CVE-2026-14750 | 5.5 medium | 0.00% | no CPE yet | A security flaw has been discovered in mjperpinosa stumasy up to 327d1b0f2915ba79d7ef8ebb74553e987609d9be. The affected element is the function Notes_controller::accessing_dictionary_authorization of the file application/PHP/objects/notes/accessing_dictionary_authorization.php. The manipulation of the argument Password results in sql injection. The attack may be performed from remote. The exploit has been released to the public and may be used for attacks. This product utilizes a rolling release system for continuous delivery, and as such, version information for affected or updated releases is not disclosed. The project was informed of the problem early through an issue report but has not responded yet. | Sun 25 Oct |
| CVE-2026-9007 | 5.5 medium | 0.00% | no CPE yet | Improper neutralization of input during web page generation ('cross-site scripting') vulnerability in HCL Notes from HCL Software allows reflected Cross-Site Scripting (XSS). Successful exploitation allows an attacker to execute arbitrary JavaScript in the context of another user. This issue affects HCL Notes: Release 12.0.2FP5HF8 on Linux 4.18.0-553.52.1.El8_10.X64_64#1. | Sat 24 Oct |
| CVE-2026-64307 | 5.5 medium | 0.00% | linux, linux_kernel | In the Linux kernel, the following vulnerability has been resolved: crypto: ccp - Do not initialize SNP for ioctl(SNP_CONFIG) Sashiko notes: > if SEV initialization fails and KVM is actively running normal VMs, could a > userspace process trigger this code path via /dev/sev ioctls (e.g., > SEV_PDH_GEN) and zero out MSR_VM_HSAVE_PA globally? Would the next VMRUN > execution for an active VM trigger a general protection fault and crash the > host? Refuse to re-try initialization if SNP is not already initialized for SNP_CONFIG. This is technically an ABI break: before if SNP initialization failed it could be transparently retriggered by this ioctl, and if no VMs were running, everything worked fine. Hopefully this is enough of a corner case that nobody will notice, but someone does, there are a few options: * do something like symbol_get() for kvm and refuse to initialize if KVM is loaded * check each cpu's HSAVE_PA for non-zero data before re-initializing * once initialization has failed, continue to refuse to initialize until the ccp module is unloaded | Sat 24 Oct |
| CVE-2026-64308 | 5.5 medium | 0.00% | linux, linux_kernel | In the Linux kernel, the following vulnerability has been resolved: crypto: ccp - Do not initialize SNP for ioctl(SNP_VLEK_LOAD) Sashiko notes: > if SEV initialization fails and KVM is actively running normal VMs, could a > userspace process trigger this code path via /dev/sev ioctls (e.g., > SEV_PDH_GEN) and zero out MSR_VM_HSAVE_PA globally? Would the next VMRUN > execution for an active VM trigger a general protection fault and crash the > host? The SEV firmware docs for SNP_VLEK_LOAD note: > On SNP_SHUTDOWN, the VLEK is deleted. That is, the initialization/shutdown wrapper here is pointless, because the firmware immediately throws away the key anyway. Instead, refuse to do anything if SNP has not been previously initialized. This is an ABI break: before, this was a no-op and almost certainly a mistake by userspace, and now it returns -ENODEV. ABI compatibility could be maintained here by simply returning 0 in the check instead. | Sat 24 Oct |
| CVE-2026-64309 | 5.5 medium | 0.00% | linux, linux_kernel | In the Linux kernel, the following vulnerability has been resolved: crypto: ccp - Do not initialize SNP for ioctl(SNP_COMMIT) Sashiko notes: > if SEV initialization fails and KVM is actively running normal VMs, could a > userspace process trigger this code path via /dev/sev ioctls (e.g., > SEV_PDH_GEN) and zero out MSR_VM_HSAVE_PA globally? Would the next VMRUN > execution for an active VM trigger a general protection fault and crash the > host? The SNP_COMMIT command does not require the firmware to be in any particular state. Skip initializing it if it was previously uninitialized. The SEV-SNP firmware specification doc 56860 does not mention SNP_COMMIT in Table 5 as a command that is allowed in the UNINIT state, but it is in fact allowed and a future documentation update will reflect that. | Sat 24 Oct |
| CVE-2026-64310 | 5.5 medium | 0.00% | linux, linux_kernel | In the Linux kernel, the following vulnerability has been resolved: crypto: ccp - Do not initialize SNP for SEV ioctls Sashiko notes: > if SEV initialization fails and KVM is actively running normal VMs, could a > userspace process trigger this code path via /dev/sev ioctls (e.g., > SEV_PDH_GEN) and zero out MSR_VM_HSAVE_PA globally? Would the next VMRUN > execution for an active VM trigger a general protection fault and crash the > host? sev_move_to_init_state() is called for ioctls requiring only SEV firmware: SEV_PEK_GEN, SEV_PDH_GEN, SEV_PEK_CSR, SEV_PEK_CERT_IMPORT, and SEV_PDH_CERT_EXPORT. After the firmware command, it does SEV_SHUTDOWN on the SEV firmware. Since these commands do not require SNP to be initialized, skip it by calling __sev_platform_init_locked() which only initializes the SEV firmware. This way SNP is not Initialized at all, and HSAVE_PA is not cleared. The previous code saved any SEV initialization firmware error to init_args.error and then threw it away and hardcoded the return value of INVALID_PLATFORM_STATE regardless of the real firmware error. This patch changes it to surface the underlying error, which is hopefully both more useful and doesn't cause any problems. Note that it is still safe to call __sev_firmware_shutdown() directly: it calls __sev_snp_shutdown_locked(), which skips SNP shutdown if SNP was not initialized. | Sat 24 Oct |
| CVE-2025-39915 | 5.5 medium | 0.00% | linux, linux_kernel | In the Linux kernel, the following vulnerability has been resolved: net: phy: transfer phy_config_inband() locking responsibility to phylink Problem description =================== Lockdep reports a possible circular locking dependency (AB/BA) between &pl->state_mutex and &phy->lock, as follows. phylink_resolve() // acquires &pl->state_mutex -> phylink_major_config() -> phy_config_inband() // acquires &pl->phydev->lock whereas all the other call sites where &pl->state_mutex and &pl->phydev->lock have the locking scheme reversed. Everywhere else, &pl->phydev->lock is acquired at the top level, and &pl->state_mutex at the lower level. A clear example is phylink_bringup_phy(). The outlier is the newly introduced phy_config_inband() and the existing lock order is the correct one. To understand why it cannot be the other way around, it is sufficient to consider phylink_phy_change(), phylink's callback from the PHY device's phy->phy_link_change() virtual method, invoked by the PHY state machine. phy_link_up() and phy_link_down(), the (indirect) callers of phylink_phy_change(), are called with &phydev->lock acquired. Then phylink_phy_change() acquires its own &pl->state_mutex, to serialize changes made to its pl->phy_state and pl->link_config. So all other instances of &pl->state_mutex and &phydev->lock must be consistent with this order. Problem impact ============== I think the kernel runs a serious deadlock risk if an existing phylink_resolve() thread, which results in a phy_config_inband() call, is concurrent with a phy_link_up() or phy_link_down() call, which will deadlock on &pl->state_mutex in phylink_phy_change(). Practically speaking, the impact may be limited by the slow speed of the medium auto-negotiation protocol, which makes it unlikely for the current state to still be unresolved when a new one is detected, but I think the problem is there. Nonetheless, the problem was discovered using lockdep. Proposed solution ================= Practically speaking, the phy_config_inband() requirement of having phydev->lock acquired must transfer to the caller (phylink is the only caller). There, it must bubble up until immediately before &pl->state_mutex is acquired, for the cases where that takes place. Solution details, considerations, notes ======================================= This is the phy_config_inband() call graph: sfp_upstream_ops :: connect_phy() | v phylink_sfp_connect_phy() | v phylink_sfp_config_phy() | | sfp_upstream_ops :: module_insert() | | | v | phylink_sfp_module_insert() | | | | sfp_upstream_ops :: module_start() | | | | | v | | phylink_sfp_module_start() | | | | v v | phylink_sfp_config_optical() phylink_start() | | | phylink_resume() v v | | phylink_sfp_set_config() | | | v v v phylink_mac_initial_config() | phylink_resolve() | | phylink_ethtool_ksettings_set() v v v phylink_major_config() | v phy_config_inband() phylink_major_config() caller #1, phylink_mac_initial_config(), does not acquire &pl->state_mutex nor do its callers. It must acquire &pl->phydev->lock prior to calling phylink_major_config(). phylink_major_config() caller #2, phylink_resolve() acquires &pl->state_mutex, thus also needs to acquire &pl->phydev->lock. phylink_major_config() caller #3, phylink_ethtool_ksettings_set(), is completely uninteresting, because it only call ---truncated--- | 19 Oct |
| CVE-2025-38466 | 5.5 medium | 0.00% | linux, debian, linux_kernel, debian_linux | In the Linux kernel, the following vulnerability has been resolved: perf: Revert to requiring CAP_SYS_ADMIN for uprobes Jann reports that uprobes can be used destructively when used in the middle of an instruction. The kernel only verifies there is a valid instruction at the requested offset, but due to variable instruction length cannot determine if this is an instruction as seen by the intended execution stream. Additionally, Mark Rutland notes that on architectures that mix data in the text segment (like arm64), a similar things can be done if the data word is 'mistaken' for an instruction. As such, require CAP_SYS_ADMIN for uprobes. | 15 Oct |
| CVE-2025-37984 | 5.5 medium | 0.00% | linux, linux_kernel | In the Linux kernel, the following vulnerability has been resolved: crypto: ecdsa - Harden against integer overflows in DIV_ROUND_UP() Herbert notes that DIV_ROUND_UP() may overflow unnecessarily if an ecdsa implementation's ->key_size() callback returns an unusually large value. Herbert instead suggests (for a division by 8): X / 8 + !!(X & 7) Based on this formula, introduce a generic DIV_ROUND_UP_POW2() macro and use it in lieu of DIV_ROUND_UP() for ->key_size() return values. Additionally, use the macro in ecc_digits_from_bytes(), whose "nbytes" parameter is a ->key_size() return value in some instances, or a user-specified ASN.1 length in the case of ecdsa_get_signature_rs(). | 15 Oct |
| CVE-2024-26816 | 5.5 medium | 0.00% | linux, debian, linux_kernel, debian_linux | In the Linux kernel, the following vulnerability has been resolved: x86, relocs: Ignore relocations in .notes section When building with CONFIG_XEN_PV=y, .text symbols are emitted into the .notes section so that Xen can find the "startup_xen" entry point. This information is used prior to booting the kernel, so relocations are not useful. In fact, performing relocations against the .notes section means that the KASLR base is exposed since /sys/kernel/notes is world-readable. To avoid leaking the KASLR base without breaking unprivileged tools that are expecting to read /sys/kernel/notes, skip performing relocations in the .notes section. The values readable in .notes are then identical to those found in System.map. | 15 Oct |
| CVE-2025-21070 | 5.5 medium | 0.00% | samsung, notes | Out-of-bounds write in the SPI decoder in Samsung Notes prior to version 4.4.30.63 allows local attackers to write out-of-bounds memory. | 8 Oct |
| CVE-2026-35565 | 5.4 medium | 0.00% | apache, storm | Stored Cross-Site Scripting (XSS) via Unsanitized Topology Metadata in Apache Storm UI Versions Affected: before 2.8.6 Description: The Storm UI visualization component interpolates topology metadata including component IDs, stream names, and grouping values directly into HTML via innerHTML in parseNode() and parseEdge() without sanitization at any layer. An authenticated user with topology submission rights could craft a topology containing malicious HTML/JavaScript in component identifiers (e.g., a bolt ID containing an onerror event handler). This payload flows through Nimbus → Thrift → the Visualization API → vis.js tooltip rendering, resulting in stored cross-site scripting. In multi-tenant deployments where topology submission is available to less-trusted users but the UI is accessed by operators or administrators, this enables privilege escalation through script execution in an admin's browser session. Mitigation: 2.x users should upgrade to 2.8.6. Users who cannot upgrade immediately should monkey-patch the parseNode() and parseEdge() functions in the visualization JavaScript file to HTML-escape all API-supplied values including nodeId, :capacity, :latency, :component, :stream, and :grouping before interpolation into tooltip HTML strings, and should additionally restrict topology submission to trusted users via Nimbus ACLs as a defense-in-depth measure. A guide on how to do this is available in the release notes of 2.8.6. Credit: This issue was discovered while investigating another report by K. | Mon 26 Oct |
| CVE-2026-72559 | 5.4 medium | 0.00% | no CPE yet | A stored cross-site scripting vulnerability in HortusFox 5.9 allows authenticated workspace members to inject persistent JavaScript into plant notes via Parsedown rendered without safe mode. Notes are rendered unescaped in the browser of every user who views the affected plant. An attacker can use this to steal session cookies or perform actions in the context of other users including administrators. | Fri 23 Oct |
| CVE-2025-55200 | 5.4 medium | 0.00% | bigbluebutton | BigBlueButton is an open-source virtual classroom. In versions prior to 3.0.13, the "Shared Notes" feature contains a Stored Cross-Site Scripting (XSS) vulnerability with the input location being the "Username" field and the output location on the "Shared Notes" page, when a user with a malicious username is editing content. This vulnerability allows a low-privileged user to execute arbitrary JavaScript in the context of higher-privileged users (e.g., Admins) who open the Shared Notes page. Version 3.0.13 fixes the issue. | 19 Oct |
| CVE-2025-65959 | 5.4 medium | 0.00% | openwebui, open_webui | Open WebUI is a self-hosted artificial intelligence platform designed to operate entirely offline. Prior to 0.6.37, a Stored XSS vulnerability was discovered in Open-WebUI's Notes PDF download functionality. An attacker can import a Markdown file containing malicious SVG tags into Notes, allowing them to execute arbitrary JavaScript code and steal session tokens when a victim downloads the note as PDF. This vulnerability can be exploited by any authenticated user, and unauthenticated external attackers can steal session tokens from users (both admin and regular users) by sharing specially crafted markdown files. This vulnerability is fixed in 0.6.37. | 18 Oct |
| CVE-2026-17538 | 5.4 medium | 0.00% | no CPE yet | The LatePoint - Appointment Booking & Reservation plugin for WordPress is vulnerable to Insecure Direct Object Reference in versions up to, and including, 5.6.9. This is due to the process_step_customer() function using is_user_logged_in() as the sole gate before merging POSTed customer data into an existing LatePoint customer, without any ownership checks. This makes it possible for authenticated attackers, with Subscriber-level access and above, to modify the personal information (first name, last name, email, phone, notes) of arbitrary LatePoint customers, and, when the contact_merge setting is 'phone', to overwrite the victim's email address and take over the account via a password reset. | 10 Oct |
| CVE-2026-41572 | 5.3 medium | 0.00% | no CPE yet | Note Mark is an open-source note-taking application. Prior to version 0.19.3, after a note-mark owner soft-deletes a public book, its notes and uploaded assets stay readable at /api/notes/{id}, /api/notes/{id}/content, the slug URL, and the asset endpoints. Unauthenticated callers who hold the note ID or the slug path retain access. GORM's soft-delete scope does not reach the raw "JOIN books ..." clauses used by the note and asset queries. This issue has been patched in version 0.19.3. | Mon 26 Oct |
Download these 1000 as CSV (the first thousand in this order) · subscribe to this list.
EPSS scores: 2026-10-28. NVD cursor: 2026-10-29 00:22. The News page shows only notable CVEs (KEV, your stack, new criticals, EPSS over 50%, or active exploitation per SSVC); this table has all of them.