Authorization bypass in RabbitMQ's MQTT topic permission handling allows a low-privileged authenticated user to broaden read and write access to topics when an operator-defined permission template embeds the {clientid} variable inside a regex character class. The flaw is an incomplete fix for CVE-2026-44838, where the escaperegexchar/1 function fails to escape the hyphen, enabling a malicious clientid to alter the character class and bypass intended topic authorization. Affected versions include RabbitMQ 4.0.0 through 4.3.2, 4.0.x before 4.0.23, 4.1.x before 4.1.14, and 4.2.x before 4.2.9; the vendor rates this medium severity (CVSS 5.1), and no public exploit code has been identified at time of analysis.
Stored cross-site scripting in Krayin laravel-crm (versions up to and including 2.2.5) lets an authenticated user with access to the TinyMCE media-upload feature bypass the SVG sanitizer by uploading an SVG file under a non-SVG filename such as payload.png; the stored extension is derived from the file's content, so the file is retained and served as SVG while the name-based sanitizer check is skipped. The injected script then executes in the browser of any user who later views the uploaded asset, within the application's origin. Authentication with low privileges (PR:L) and passive victim interaction (UI:P) are required, impact is confined to the victim's browser context rather than server compromise, and no public exploit code was identified at time of analysis. This is a genuine but low-priority stored XSS - a related nested-configuration-field upload path stores files without SVG sanitization as well.
Local, unprivileged attackers can bypass the Ironshield tvk.sys driver's authentication to gain access to privileged IOCTL functionality on Windows hosts running IRONMACE Ironshield 1.0.0.167 with the driver loaded. The driver checks for literal publisher and root-certificate strings in WIN_CERTIFICATE data instead of cryptographically validating the PKCS signature, so any binary embedding 'IRONMACE Co., Ltd.' and 'DigiCert Trusted Root G4' is accepted. Rated CVSS 5.1, this local-only flaw limits impact to privileged IOCTL access rather than confirmed full system compromise; no public exploit identified at time of analysis.
Stored cross-site scripting (XSS) in the AIL Framework tag selector (var/www/static/js/tags.js) allows an authenticated user with permission to create custom tags to inject JavaScript that executes in the browser of another authenticated user who loads a page rendering the tag selector, potentially leading to session hijacking or unauthorized data access within the application origin. The vulnerability (CWE-79) is persistent and requires the attacker to hold a valid account with tag-creation rights (PR:L), while the victim must be logged in and view the affected UI (UI:P, passive). A vendor fix is available via commit b2d0ed05; no public exploit code has been identified at time of analysis.
Stored cross-site scripting in the StockAgile management panel and REST API lets an authenticated user persist arbitrary JavaScript through category fields, which then executes in the browser of any other authenticated user who views the poisoned category view. The flaw affects the '/inventory/configuration/categories' REST endpoint, where parameters such as 'code' and 'name' are stored without adequate filtering or validation before being rendered in the web panel. Exploitation requires a valid StockAgile account and passive interaction from a second panel user, so impact is confined to the victim's browser session; no KEV entry or public exploit code was identified at time of analysis, and a vendor patch is available. The self-reported CVSS 4.0 base score is 5.1 (AV:N/AC:L/PR:L/UI:P), consistent with our independent CVSS 3.1 assessment of 5.1.
Stored cross-site scripting in the StockAgile inventory management platform allows an authenticated user with permission to write category configuration data to persist malicious JavaScript through the REST endpoint '/inventory/configuration/categories' (fields such as 'code' and 'name'). The injected payload is later rendered without proper output encoding in the management web panel, so it executes in the browser session of any authenticated user who views the affected category - a low-privilege, authenticated attacker (PR:L) with passive victim interaction (UI:P) can run script in the victim's session, though impact remains limited to confidentiality and integrity of that session with no server-side code execution or availability loss. Severity is modest (CVSS 5.1, CWE-79); no public exploit code has been identified at time of analysis, and a vendor patch is available per the INCIBE advisory.
Stored cross-site scripting in the StockAgile API and management panel lets a remote authenticated user persist malicious JavaScript into the REST endpoint '/inventory/configuration/serial-number-types' through text parameters such as 'code' and 'name', which the server fails to validate or encode before rendering them back in the web panel. The payload executes in the browser of any authenticated operator who subsequently opens the affected panel view, in the context of that user's session, but it does not compromise the server itself. Exploitation is not unauthenticated: the CVSS 4.0 vector reports PR:L, so the attacker must already hold a valid account with write access to that endpoint, and the impact stays within the victim's browser context (VC:L/VI:L/VA:N). No public exploit code or confirmed active exploitation was identified at time of analysis, and while a vendor patch is available, the issue is best handled as routine-priority patching rather than an emergency given its low severity and privilege prerequisites.
Stored cross-site scripting in the StockAgile management panel lets an authenticated user who can write to the REST endpoint '/inventory/configuration/serial-number-types' persist malicious JavaScript through the 'code', 'name' and other text fields, which is then served unescaped and executes in the browser of any other authenticated user who later opens the poisoned configuration view. Exploitation is not self-contained: the CVSS vector marks the attacker as authenticated (PR:L) and requires a second user to passively load the affected panel, so impact stays client-side with no server-side code execution or availability loss. The vendor has issued a patch through the INCIBE advisory, and no public exploit identified at time of analysis; severity is assessed as modest rather than emergency-level given the authentication barrier and the need for a victim to view the injected configuration.
Stored cross-site scripting in the StockAgile inventory management platform allows an authenticated user to persist malicious JavaScript into product-variant records via the REST endpoint '/inventory/configuration/variants'. Because the 'code', 'name', and other text fields are not sanitized before being rendered in the web management panel, the injected script executes in the browser of any authenticated operator who later views the affected configuration page, enabling session hijacking or panel actions in that user's context. Exploitation requires a valid panel account plus a second authenticated user to trigger rendering, no public exploit code has been identified at time of analysis, and a vendor patch is already available, making this a moderate rather than urgent priority.
Stored cross-site scripting in StockAgile allows an authenticated low-privileged attacker to inject persistent JavaScript through text fields such as code and name in the REST endpoint /inventory/configuration/pricing-tiers, which is then rendered in the management panel for other authenticated users. Exploitation requires a valid StockAgile account to write the payload and a second authenticated user to view the affected pricing-tier data, with impact limited to script execution in the panel's browser context and no availability impact. The issue is assessed as a moderate, not urgent, priority; no public exploit code was identified at time of analysis, and there is no confirmed active exploitation.
Stored cross-site scripting in the StockAgile API and management panel allows an authenticated remote attacker to persist arbitrary JavaScript into payment-method configuration records via the REST endpoint '/inventory/configuration/payment-methods', using text parameters such as 'code' and 'name' that are neither validated nor encoded before being rendered back to users. Because the injected script only fires when a second authenticated user opens the affected configuration in the web panel (CVSS UI:P / UI:R), exploitation requires both an attacker account with access to the payment-method configuration feature and a victim who views the poisoned data, and impact is confined to the victim's browser session. No public exploit code has been identified at time of analysis, and the vendor has published a fix. This is a genuine but low-priority stored XSS.
InvoicePlane releases prior to 1.7.2 store and serve image attachments (invoice, quote, and other attachment uploads) without stripping EXIF metadata, so any authenticated recipient with whom a picture is shared can recover embedded GPS coordinates, capture timestamps, camera/device identifiers, and similar details that the uploader never intended to disclose. The assessed vector requires an authenticated low-privileged user (PR:L) on the network to view the shared image, and exploitation is entirely contingent on the uploader having attached a photo that actually carries EXIF data - screenshots, re-encoded images, and scanned documents expose nothing, which keeps the practical impact low and conditional. Exploitation yields only whatever metadata happens to be present in the file, so this is a privacy leak rather than a code-execution or account-takeover flaw; no public exploit code has been identified and the issue is not listed on CISA KEV, though note that the 1.7.2 mitigation ships disabled by default and must be explicitly enabled to be effective.
Authenticated directory traversal in the WordPress plugin SSL Zen - SSL Certificate Installer & HTTPS Redirects (all versions up to and including 4.7.42) allows a user with administrator-level capabilities to read the contents of arbitrary files on the server through the 'file_name' parameter, exposing sensitive data such as wp-config.php or other credential-bearing files. The flaw is a classic CWE-22 path traversal (CVSS 3.1: AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N, base 4.9 Medium), and the high privilege prerequisite substantially limits real-world impact because WordPress administrators already hold broad file-read/upload capabilities; our assessment rates this as a genuinely low-priority issue. No public exploit code has been identified at time of analysis and the CVE is not listed in CISA KEV; no EPSS score was supplied.
Cross-site scripting in Teldat's Regesta Smart HD-PLC powerline communications device (model TLDPH16D2, firmware 11.02.06.00.02) allows an attacker who already has authenticated access to the web management interface to inject a payload through the 'cmdcookie' parameter of /upgrade/index.html, which then executes in the browser of a logged-in user who triggers the crafted request. The vulnerability is confirmed only for firmware 11.02.06.00.02 and carries a low CVSS 4.0 base score of 4.8, consistent with an independent assessment of CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N that requires prior authentication (PR:L) and mandatory victim interaction (UI:R). No public exploit code and no confirmed active exploitation were identified at time of analysis, and the niche industrial deployment of these PLC devices further narrows real-world exploitability.
Authenticated RabbitMQ Server 4.2.0 through 4.2.8 and 4.3.0 through 4.3.2 users who hold only 'configure' permission on one exchange can bypass the alternate-exchange authorization check through the AMQP 1.0 management API, silently redirecting unrouteable messages into a target exchange on which they have no write permission. The defect is a missing authorization check (CWE-862) in the PUT /exchanges/:name handler, reachable whenever AMQP 1.0 is enabled - the default in RabbitMQ 4.x - while the equivalent AMQP 0-9-1 channel path already enforces the check. Impact is confined to routing integrity with no confidentiality or availability loss; no public exploit code has been identified at time of analysis, and vendor-released patches are available in 4.2.9 and 4.3.3.
Cross-site scripting in the WikiLambda extension for MediaWiki allows a high-privileged wiki contributor to store script-bearing markup that executes in the browser of another user who views the crafted content, giving limited client-side impact (CVSS 3.1 base vector AV:N/AC:L/PR:H/UI:R/S:C/C:L/I:L/A:N; vendor-published CVSS 4.0 score 4.8). Only the pre-release version 1.47.0-alpha of the extension is affected, and the flaw has been remediated on the master branch, so no stable numbered MediaWiki release carries the vulnerable code; realistic exposure is confined to development or alpha deployments that have installed the extension. No public exploit code has been identified at time of analysis and the issue is not listed as confirmed actively exploited (CISA KEV); this is a genuinely low-priority XSS despite the CWE-79 label.
Stored cross-site scripting in the MediaWiki TemplateSandbox extension allows low-privileged authenticated editors to inject arbitrary JavaScript into template sandbox previews, which then executes in the browser of any user induced to view the crafted content. Exploitation requires the extension to be installed, a valid low-privileged account to submit the malicious wikitext, and victim interaction with the preview. No public exploit code or active exploitation has been identified, and the impact is limited to browser-side script execution in the wiki origin rather than server compromise.
Authorization bypass in InvoicePlane versions prior to 1.7.2 lets unauthenticated remote attackers satisfy the application's primary role check when the instance is configured with a non-standard session backend that returns non-string scalar values for the session user_type key; the User_Controller constructor compares that session value against the required role using PHP's loose inequality operator, so type juggling can pass a check it should fail. Against the default CodeIgniter session store, which returns strings, the comparison behaves correctly and the bypass does not occur, which is why the assessed CVSS is 4.8 with high attack complexity and impact limited to low confidentiality and integrity. No public exploit identified at time of analysis.
Stored cross-site scripting in InvoicePlane 1.7.2-beta-1 and earlier lets an authenticated administrator who can edit client records persist an attribute-breaking payload in the client_email field, which the invoice and quote mailer views then render unescaped inside a double-quoted to_email value attribute. When the mailer feature is configured for the affected client and a second authenticated administrator opens the related mailer page, the injected JavaScript runs in the InvoicePlane origin and can act with that victim's session. Exploitation requires two separate high-privilege admin accounts plus victim user interaction, which keeps this a genuine but low-priority issue; no public exploit code has been identified at time of analysis, and the flaw is fixed in version 1.7.2.
Local low-privileged users can trigger a genuine but low-urgency race condition in the Linux kernel's IPv6 multicast list handling, causing a crash or denial of service on kernels built with IPv6 support. The defect affects kernels before the vendor fixes, traces back to approximately Linux 2.6.38, and is fixed in 7.2.7 and 7.3-rc2 per EUVD. No public exploit identified at time of analysis, EPSS is 0.17% (6th percentile), and the this_month priority label reflects limited, local-only, timing-dependent exposure.
Uninitialized-mutex use in the Linux kernel Bluetooth HCI core can be triggered by a local low-privileged user who causes an HCI controller flagged with quirks such as HCI_QUIRK_RAW_DEVICE (and therefore HCI_UNCONFIGURED) to be registered while the power_on work item races ahead of msft_register() initialization. The window is a narrow timing race in hci_register_dev(), where hdev->msft_data is published before mutex_init(&msft->filter_lock) completes, so hci_power_on() -> hci_dev_do_close() -> msft_do_close() can lock an uninitialized mutex, producing a DEBUG_LOCKS warning and a kernel warning/backtrace (availability impact, no confidentiality or integrity effect). EPSS is 0.17% (5th percentile), there is no CISA KEV listing, and no public exploit code has been identified at time of analysis; vendor-released patches exist for the affected stable branches.
LDAP filter bypass in GLPI versions prior to 10.0.26 and 11.0.8 allows an authenticated hotliner or technician with access to the user-import feature to inject crafted criteria and read LDAP objects that the configured default filter was intended to exclude. The issue is a limited information-disclosure flaw: it does not grant write access, code execution, or access to GLPI's own data, and exploitation requires an existing LDAP integration with a configured default filter. No public exploit code was identified at time of analysis, and NVD rates it CVSS 4.6.
RabbitMQ Shovel plugin before 4.3.3, 4.2.9, 4.1.14, and 4.0.23 can write plaintext AMQP credentials from shovel worker GenServer state into crash dump files because the process does not implement the OTP format_status/2 callback; a crash (e.g., network partition) triggers the SASL error handler to serialize the full state, including deobfuscated amqp://user:password@host URIs. Exploitation is not remote: it requires the Shovel plugin to be configured with credentialed URIs, a subsequent crash, and authenticated high-privileged read access to the node's error log or crash dump (CVSS 3.1 PR:H), exposing credentials for the separate upstream/downstream brokers rather than the RabbitMQ node's own data. No public exploit has been identified at time of analysis, and vendor patches are available in the fixed versions.
Symlink traversal in the drag-and-drop remote staging path of kitty 0.47.0 up to (but not including) 0.49.0 lets a program that can write to the terminal create new files (mode 0644) and directories (mode 0755) at arbitrary absolute paths writable by the user running kitty, by declaring two identically named entries - the first a symlink to a chosen absolute path, the second a directory. Exploitation is local and requires the victim to actively initiate a drag-and-drop operation from the terminal (UI:A); the assessed vector is CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N (CVSS 4.0 base 4.6), so impact is limited to integrity of newly created paths, and O_CREAT|O_WRONLY|O_EXCL semantics prevent overwriting any pre-existing file. No public exploit code identified at time of analysis, and the vendor released a fix in 0.49.0 that refuses symlinked directory entries during remote drag staging.
Use-after-free in the drag-and-drop source path of the kitty terminal emulator (versions 0.47.0 up to but not including 0.49.0) allows any program that controls the terminal's output byte stream to make the terminal read from and write to freed heap memory while the user is actively dragging content out of the window. The flaw lives in drag_remote_file_data() in kitty/dnd.c, which keeps a DragRemoteItem pointer into an array that the error path's cancel_drag()/drag_free_offer() teardown frees, then continues to dereference and write through it; per the assessed vector this is a local, user-interaction-required issue (CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:L) with integrity and availability impact only and no confidentiality impact, matching the vendor's low 4.6 CVSS 4.0 base score. No public exploit code was identified at time of analysis, and the issue is not confirmed actively exploited (not in CISA KEV); a vendor patch is available in kitty 0.49.0.
RabbitMQ Management versions 3.13.0 through 3.13.18, 4.0.23, 4.1.14, 4.2.9 and 4.3.4 render an attacker-controlled AMQP queue name as unescaped HTML in an authorization-error reason when the OAuth management UI is enabled, allowing an injected <base> element to retarget the UI's automatic relative refresh. An authenticated attacker holding queue 'configure' permission can therefore cause a management administrator who clicks 'Get Message(s)' on the crafted queue to send their Authorization header to an attacker-controlled endpoint whose CORS policy accepts the management origin. Exploitation requires a stacked set of preconditions - non-default OAuth UI, attacker queue-configure rights, an administrator who can see but cannot read the queue, a victim click, a Content Security Policy lacking base-uri and connect-src, and an attacker endpoint that permits the management origin via CORS - which substantially limits real-world risk; no public exploit identified at time of analysis, and the issue is rated MEDIUM (CVSS 4.0 base 4.5).
Reversed argument ordering in the Linux kernel IPVS connection-synchronization sender (sync protocol version 1) causes hton_seq() to write to the wrong buffer, leaving 24 bytes of a kmalloc-backed sync message uninitialized while clobbering live connection sequence state with values read back from that buffer. The flaw, tracked as CVE-2026-98078, affects Linux kernels since the sync code was introduced at 2.6.39 and is reachable only on hosts acting as IPVS/LVS directors that have the sync daemon explicitly enabled in master/sender mode on protocol version 1 - a non-default, specialized load-balancer cluster configuration. The CVSS vector (AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L) and the 4.4 base score reflect local access with low privileges and limited confidentiality, integrity, and availability impact; EPSS is only 0.20% (9th percentile) and there is no public exploit identified at time of analysis, making this a low-priority defensive-patch issue rather than an urgent threat.
Salt deduction in PostgreSQL Anonymizer prior to 3.2.3 allows an authenticated low-privileged masked role to bypass RESTRICTED function protections by calling anon.hash() from inside a sub-select, collecting (seed, hash_output) pairs and performing an offline brute-force attack to recover the masking salt. This is a low-severity information-disclosure issue (CVSS 4.3, PR:L) that weakens masking guarantees but does not directly reveal plaintext or grant privilege escalation; no public exploit identified at time of analysis and no CISA KEV entry was identified. The issue is fixed in PostgreSQL Anonymizer 3.2.3 and later.
Authorization bypass in the Blog2Social: Social Media Auto Post & Scheduler plugin for WordPress (all versions through 9.1.0) allows any authenticated user holding Contributor-level access or higher to act on other users' social-media scheduling data, including viewing, modifying, or deleting records. Because the plugin's b2s_security_nonce is rendered on the post-edit meta box that Contributors can already access, the nonce does not function as a privilege barrier, so attackers can read another user's network authentication IDs and scheduled post content, overwrite Open Graph and Twitter Card metadata on posts they do not own, rebind another user's social-network authorization, and mass-hide scheduled posts sitewide. Exploitation requires a low-privileged account on a site running the affected plugin; no public exploit code has been identified at time of analysis, and no CISA KEV entry is associated with this CVE. Practical exposure is limited to multi-author or membership sites that grant Contributor or higher roles to untrusted users.
Authorization bypass in the OpenStation - Desktop Windows, Dock & Virtual Desktops for WP Admin WordPress plugin (slug desktop-mode) through version 1.1.7 lets any authenticated user - even one holding only the default 'read' capability that every Subscriber gets - read the title, status, date, permalink and a 300-character content excerpt of private, draft, pending and future posts, as well as the body and AI-moderation verdicts of unapproved and spam comments. The intended 'custom-level access plus enabled AI feature' prerequisite collapses because any logged-in user can self-enable ai.enabled by posting to /desktop-mode/v1/os-settings from the /openstation/ portal. It is a read-only confidentiality leak with no write or code-execution impact, no public exploit identified at time of analysis, and no CISA KEV or EPSS signal, which is consistent with the genuinely low-priority assessment.
Bypass of failed-login rate limiting in django-allauth before 65.19.4 allows unauthenticated remote attackers to obtain a higher effective number of login attempts in certain common configurations by submitting diacritic variants of the same username or email. The flaw is a low-severity defense-in-depth weakness, not a directly exploitable breach: CVSS 3.1 score 3.7 with AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N, requiring specific normalization and rate-limit configuration behavior; it does not grant access without an underlying weak or guessable credential. Vendor-released patch: 65.19.4. No public exploit identified at time of analysis, and no CISA KEV active-exploitation confirmation was provided.
GraphQL query injection in Rapid7 Bulk Export MCP 0.2.5 through 0.6.1 allows an authenticated high-privileged actor who can influence the export_id argument used by the check_rapid7_export_status and download_rapid7_export tools to terminate the intended export(id: "...") selection and append attacker-controlled root-level selections such as schema introspection. The impact is confined to confidentiality (CVSS 2.7, CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N), because every injected query executes inside the operator's own already-authenticated Rapid7 API key scope and cannot cross a tenant or account boundary - a directly-malicious operator gains nothing beyond what direct API access already provides, so realistic exposure requires a compromised or careless upstream MCP client or indirect prompt injection forwarding an unvalidated identifier. There is no confirmed active exploitation (not in CISA KEV) and no public exploit identified at time of analysis; the vendor-released fix is version 0.6.2, which parameterizes export_id as a GraphQL variable.
Hard-coded cryptographic key material embedded in the Tohoku Electric Power 'Yorisou e Net' Android and iOS apps can be recovered by inspecting or reverse-engineering the installed application package, potentially exposing whatever data or service that key protects. Both mobile builds are affected (per the vendor CPE entries), and the CVSS vector indicates physical access to the device (AV:P) with no authentication (PR:N) and no user interaction (UI:N) required, so the practical gate is simply obtaining and analyzing the app rather than any remote precondition. Impact is confined to a low-confidence confidentiality loss (C:L, no integrity or availability effect) and the advisory does not specify what the recovered key protects downstream; all signals point to a low-priority issue, with no public exploit code identified at time of analysis and no EPSS or KEV data provided. The JVN advisory JVN93985674 is the primary coordinated-disclosure reference.
Stale OAuth authentication-mechanism preferences can survive a logout in the RabbitMQ management UI on versions 4.2.0 through 4.2.7 and 4.3.0/4.3.1, because the plugin emits a non-ASCII cookie name when it tries to clear the strict_auth_mechanism or preferred_auth_mechanism cookie, and RFC 6265-compliant browsers refuse to delete a cookie whose name is not a valid token. The practical effect is limited to a persisted UI preference carrying across logout/login cycles; there is no code execution, data exfiltration, or confidentiality or availability impact, which is consistent with the NVD CVSS 4.0 base score of 2.3 and with the independent CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:L/A:N assessment. Exploitation requires the management UI to be in active use and a logout/login cycle to occur, and no public exploit code or evidence of active exploitation was identified at time of analysis.
Authenticated agents on Zammad helpdesk instances can retrieve the AI provider error strings recorded for AI analytics runs belonging to tickets they are not authorized to view, simply by passing an arbitrary ai_analytics_run_error_id to the ticket summarize endpoint. The exposure is confined to the stored provider error message - no ticket content, customer data, or conversation text is disclosed - and the AI summarize/analytics feature must be in use with at least one errored run present for the attack to succeed. The vendor-published CVSS 4.0 score is 2.3 and our independent assessment rates it low severity, with only a limited confidentiality impact; no public exploit code or active exploitation has been identified at time of analysis, and the flaw is fixed in Zammad 7.1.2.
RabbitMQ OAuth credential refresh keeps revoked runtime tags on live AMQP connections in versions 3.13.0 up to the fixed 3.13.19, 4.0.24, 4.1.15, 4.2.10 and 4.3.5 releases, so an authenticated client (CVSS PR:L) that already held the privileged `impersonator` tag can keep publishing messages with a foreign AMQP userid after that privilege is withdrawn. The defect only affects connections that once held `impersonator` and then refresh in place to a same-username OAuth token that no longer grants it, with `rabbit_auth_backend_oauth2` (or an equivalent refresh-capable backend) enabled; a freshly opened connection using the downgraded token correctly refuses the same publish. No public exploit code has been identified at time of analysis, and the practical impact is a stale privilege-revocation gap for an already-privileged session rather than a route for an ordinary user to gain new privileges.
Authenticated peers connected to a Windows RustDesk host running a version before 1.5.0 can bypass the one-way file transfer setting and pull files straight out of the victim's clipboard. Because the same option that is meant to prevent the local machine from serving clipboard files is the one being ignored, an attacker who already holds a valid remote session can send crafted clipboard-redirection messages (FormatDataRequest / FileContentsRequest) and, by supplying the known FileGroupDescriptorW format identifier, receive the contents of any file the user has copied. Rated only 2.3 under CVSS v4.0 (assessed CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N), the issue yields confidentiality impact only, requires an authenticated peer relationship plus a clipboard that already holds files, and no public exploit has been identified at time of analysis.
Zammad helpdesk instances prior to 7.1.2 expose a legacy destroy_form action on AttachmentsController that deletes temporary UploadCache store records using only a caller-supplied form_id and performs no ownership verification (CWE-862), so an authenticated user who knows another user's pending-upload UUID can silently wipe that user's in-progress attachments before the ticket or article is submitted. Exploitation requires a valid account on the instance plus knowledge of the victim's non-enumerable form_id UUID and only affects files still in the transient pre-submission cache, which is why the base score is a low 2.3 under CVSS 4.0 (equivalently AV:N/AC:H/PR:L/UI:N/C:N/I:L/A:L on CVSS 3.1). No public exploit code or confirmed active exploitation was identified at time of analysis, and the flaw is fixed in Zammad 7.1.2.
Stored cross-site scripting in the MediaWiki Cargo extension through version 3.9.4 lets an authenticated user with content-editing privileges embed script payloads in Cargo-managed data that execute in the browser of any other user who later views the rendered Cargo output. The assessed severity is low, with a CVSS 4.0 base score of 2.3 and a 3.1 vector of AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:N, so impact is confined to the victim's browser session (low confidentiality and integrity, no availability effect) and no public exploit identified at time of analysis. Because Cargo is an optional extension, only wikis that have it installed at 3.9.4 or earlier are affected, and each successful attack also requires a second user to view the poisoned page, which keeps attack complexity high.
Mutation XSS in the Elixir library LazyHTML 0.1.0 through 0.1.12 lets attacker-supplied markup slip past element and attribute allowlist filters and turn into live HTML when the filtered document is serialized for display. The defect is in LazyHTML.to_html/2 and LazyHTML.Tree.to_html/2, which decide whether to escape an element's text from the tag name alone, so a style or script element inside SVG or MathML foreign content is parsed with character references decoded yet serialized as an unescaped HTML raw-text element; encoded markup such as </style><img src=x onerror=...> inside <svg><style> therefore closes the element on re-parse and executes. Exploitation is unauthenticated and remote but conditional: the consumer application must parse untrusted HTML with lazy_html, filter the document or tree, and serialize the result to a victim who views it (user interaction required), which keeps real-world impact low (scope change, low confidentiality and integrity, no availability impact); no public exploit identified at time of analysis, and the vendor has shipped a fix in 0.1.13.
Information disclosure in the Zammad helpdesk knowledge base lets an authenticated user who holds the knowledge_base.editor permission in at least one category see answer titles and updated_at timestamps belonging to categories where they have no editor rights, exposed through the global quick search. The leak only occurs in deployments that use granular, per-category permission assignments with differing editor roles; category names are not exposed and opening a leaked answer returns 'Page not found,' so no answer body content is accessible. Exploitation requires a valid authenticated account with the editor permission (PR:L/H depending on the scoring system) and is rated low severity (CVSS 4.0 base 2.1), with no public exploit identified at time of analysis.
Administrator-tagged accounts on RabbitMQ can silently delete users that carry the 'protected' tag by calling the management plugin's POST /api/users/bulk-delete endpoint, which skips the protected-user guard that the single-user DELETE /api/users/:name path enforces. The flaw affects RabbitMQ 3.13.0 up to 3.13.14 and 4.0.x, 4.1.x, and 4.2.x releases before 4.0.20, 4.1.11, and 4.2.6, but only when the rabbitmq_management plugin is enabled and only for an attacker who already holds the highest management privilege ('administrator' tag), so the outcome is integrity loss (destruction of hardened service accounts) rather than any escalation of access. No public exploit identified at time of analysis, no confirmed active exploitation (CISA KEV), and no EPSS score was provided; the assessed CVSS:3.1 vector is AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:N (CVSS 4.0 base 2.1), and realistic risk is confined to insider misuse, a compromised admin credential, or accidental bulk deletion.
Authenticated Zammad agents holding the ticket.agent permission can read knowledge base answer content they are not authorized to access by invoking the KnowledgeBase::Answer::Suggestion::Content::Transform GraphQL mutation with a translation ID outside their KB category permissions. This low-severity authorization bypass affects Zammad versions prior to 7.0.2 and requires the attacker to know a valid translation ID; it is fixed in 7.0.2 and no public exploit code or active exploitation has been identified at time of analysis.
In the Linux kernel, the following vulnerability has been resolved: net: usb: cx82310_eth: drop URB after 0xffff reboot sentinel to prevent partial_data heap overflow The 0xffff length sentinel detects a router reboot and schedules re-enabling of ethernet mode, but then falls through to the rest of the loop body. The next check is } else if (len > CX82310_MTU) { which is the else of the just-matched if -- it never fires for len == 0xffff. The MTU bound that normally caps the incomplete-packet save path is silently bypassed. With 0xffff > skb->len always true (rx_urb_size is 4096), the incomplete-packet branch saves dev->partial_len = skb->len bytes into dev->partial_data. partial_data is kmalloc(hard_mtu) = kmalloc(CX82310_MTU + 2) = 1516 bytes, but skb->len after the 2-byte header pull can be up to 4094. A device that sends a 4096-byte URB starting with [0xff 0xff] therefore copies 4094 device-provided bytes into a buffer allocated for 1516 bytes, exceeding its requested size by 2578 bytes. The next URB then reads dev->partial_len (4094) back from the same 1516-byte buffer and dev->partial_rem (65535 - 4094 = 61441) from the new URB's ~4KB skb, both well past their allocations, and delivers the spliced result as a 64KB "frame" to the network stack. Bail out of rx_fixup after scheduling the re-enable work; the remainder of a reboot-marker URB is not meaningful packet data. This restores the invariant that partial_len < CX82310_MTU + 2 on the save path, since every other route there has already passed the MTU check.
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix cifsFileInfo reference leak in deferred close When cifs_close() defers a close, it hands the cifsFileInfo reference of the closing struct file to the queued work. Each execution of smb2_deferred_work_close() drops one such reference. deferred_close_scheduled can be false while the work is pending: the workqueue clears PENDING when the callback starts to run, before the callback clears the flag under deferred_lock. A close in that interval requeues the running work, and the callback then clears the flag, leaving the requeued work pending with the flag down. A later cifs_open() can reuse the handle and its cifs_close() reaches the same branch: queue_delayed_work() fails because the work is still pending, but cifs_close() returns without dropping the closing file's reference. The cifsFileInfo count stays pinned and its tlink, dentry and server handle are leaked. Check the return value and hand off the reference only when work was actually queued. Otherwise, use the shared _cifsFileInfo_put(), like the mod_delayed_work() branch above: the pending execution already owns its reference. This issue was found by an in-house static analysis tool.
In the Linux kernel, the following vulnerability has been resolved: bootconfig: Fix integer overflow in initrd size check Sashiko reported that in get_boot_config_from_initrd(), a crafted initrd with a huge bootconfig size (such as 0xFFFFFFFF) can cause the pointer arithmetic: data = ((void *)hdr) - size; to wrap around on 32-bit systems (or when pointer subtraction overflows). Because data wraps around, the subsequent bounds check: if ((unsigned long)data < initrd_start) evaluates to false, bypassing the check. The kernel then calls xbc_calc_checksum(data, size), which attempts to read 4GB of memory, hitting unmapped pages and triggering a fatal kernel page fault during early boot. Furthermore, on 64-bit systems with an initrd > 4.29 GB, an unbounded 32-bit size can similarly bypass the initrd_start check. Fix this by: 1. Ensuring the initrd is at least large enough to contain the bootconfig footer and verifying hdr is within the initrd bounds. 2. Checking that size does not exceed XBC_DATA_MAX and does not exceed the available space between initrd_start and hdr before performing pointer subtraction.
In the Linux kernel, the following vulnerability has been resolved: ipv6: flowlabel: cap duplicate leases per socket ipv6_flowlabel_get() allocates an ipv6_fl_socklist entry for every successful GET. The recheck path for a compatible existing flowlabel links another lease without applying any lease admission check. Repeated GET requests for one shareable label can therefore grow a socket's lease list without bound. Reject a new unprivileged lease once the socket already holds FL_MAX_PER_SOCK leases. Check this on the shared recheck path so reuse of a globally interned label, including the fl_intern() collision path, is covered as well. New-label admission remains under the existing mem_check() policy. Use capable(CAP_NET_ADMIN) rather than ns_capable(), matching mem_check(). An unprivileged user must not bypass the cap by creating a user namespace and a netns where they have CAP_NET_ADMIN, which would still consume host memory. Check the capability only when the socket reaches the limit, so successful unprivileged GET requests below the cap do not generate a capability audit. Do the admission check before updating linger and expires so a rejected GET does not refresh the shared label, matching the existing socket-list allocation failure path.
In the Linux kernel, the following vulnerability has been resolved: x86/mm/pat: Acquire init_mm read lock on attribute changes to avoid UAF A previous commit protected against races between ptdump and CPA collapse, however one still exists between attribute changes and collapse as reported by Denis V. Lunev (linked). When an attribute change arises, a lockless page table walker obtains a PTE entry, which is later written to via set_pte_atomic(): ... -> change_page_attr_set_clr() -> __change_page_attr_set_clr() -> __change_page_attr() -> _lookup_address_cpa() -> lookup_address_in_pgd_attr() -> [ lockless page table walker ] -> set_pte_atomic() There is nothing preventing a concurrent CPA collapse which can free the PTE that was retrieved here, resulting in a use-after-free. With the mmap write lock taken on init_mm over CPA collapse, resolve this race by acquiring an mmap read lock on init_mm over __change_page_attr_set_clr(). This locks across the whole operation over which the walk and the PTE entry write occurs, solving the race. It is safe to do this here, as no spinlocks are held upon entry to __change_page_attr_set_clr(). However, the lock must not be held over an allocation, as allocation can trigger reclaim and shrinkers may call into CPA recursively, making deadlocks possible (init_mm -> ... -> fs_reclaim -> init_mm). A page table is allocated when a huge page needs to be split: -> change_page_attr_set_clr() -> __change_page_attr_set_clr() -> __change_page_attr() -> split_large_page() [ pagetable_alloc() ] -> __split_large_page() Avoid deadlocks by dropping the mmap lock across pagetable_alloc() in split_large_page() and track whether this is needed by adding a new 'init_mm_read_locked' flag to struct cpa_data. This is safe as __split_large_page() (called with locks re-established) revalidates that the page table entry is the same as it was prior to the locks being dropped and __change_page_attr() repeats the entire page table walk whenever a split occurs, so concurrent split and collapse are accounted for. Concurrent ptdump is also safe as the lock is only dropped over page table allocation during which time the page table has not yet been modified. The CPA_COLLAPSE flag is only set by set_memory_rox(), which exclusively operates upon vmalloc ranges, and on x86 only within the module mapping space. This is important, because some callers directly invoke __change_page_attr_set_clr(), bypassing this lock. However, none of these operate within the module mapping space. * cpa_process_alias() - a recursive helper called by __change_page_attr_set_clr(). * __set_memory_enc_pgtable() - operates on the direct mapping and (via __vmbus_establish_gpadl()) the vmalloc mapping space. * __set_pages_[n]p() - called by set_direct_map_[invalid, default, valid]_noflush(), __kernel_map_pages() - operates on the direct map. * kernel_[un]map_pages_in_pgd() - operates on EFI ranges. This work is based upon Denis V. Lunev's excellent analysis of the bug with gratitude. [ dhansen: move to imperative voice in changelog ]
In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_u32: fix duplicate handle when node ID pool is exhausted gen_new_kid() falls back to returning max (htid | 0xFFF) when both idr_alloc_u32() ranges are full, instead of reporting an error. u32_change() trusts that value and inserts a new knode with a handle that is already live in the hash table, breaking handle uniqueness within the table's node ID space. The handle was never reserved in ht->handle_idr, so every later error path that does idr_remove(&ht->handle_idr, handle) removes the reservation of a different, live knode, which is then reused - one failed add compounds into further duplicates. The 4095 limit is per (table, bucket) - ht->handle_idr is per hash table and the range is derived from htid (bucketid), so a table with divisor 256 can legitimately hold 256*4095 knodes. The sibling helper gen_new_htid() has the same silent in-band failure: it returns 0 when the tp_c handle pool (1..0x7FF) is full, and u32_init() publishes the root hash table with handle 0 without checking. Two root tables with handle 0 alias in u32_lookup_ht(), allowing cross-tcf_proto knode add/lookup/delete. Add the same exhaustion check that the divisor path already has. Return an error so u32_change() fails with ENOSPC/ENOMEM when the node ID space is exhausted, and so u32_init() fails with -ENOMEM when the hash table ID space is exhausted. The extack message distinguishes pool exhaustion (-ENOSPC) from a transient allocation failure (-ENOMEM). Conditions to recreate the bug: - CONFIG_NET_SCHED=y, CONFIG_CLS_U32=y (or =m with module loaded) - Create a clsact qdisc on a device, then add 4095 u32 filters with auto-generated handles to fill the node ID space for the root hash table (single bucket). The 4096th auto-handle filter add triggers the duplicate handle (fh 800::fff reused). Reachable at Level 2 (unshare -Urn, namespace-local CAP_NET_ADMIN). - For gen_new_htid: create 2047 u32 proto entries on the same block to fill the tp_c handle pool, then create one more. The root table gets handle 0 and aliases with other handle-0 root tables.
In the Linux kernel, the following vulnerability has been resolved: ALSA: ump: do not touch legacy_rmidi before it exists snd_ump_parse_endpoint() sets ump->parsed on every exit, including error, before the caller attaches the legacy rawmidi device. ump_handle_ep_name_msg() then treats parsed as "legacy_rmidi is live" and calls ump_legacy_set_rawmidi_name(), which snprintf()s into ump->legacy_rmidi->name. If a UMP packet arrives in that window (IRQ path from snd_ump_receive), legacy_rmidi is still NULL (KASAN null-ptr-deref in snprintf). Guard the legacy helpers. parsed only means endpoint info was parsed, not that legacy_rmidi exists.