CVE-2026-93365
Bludit CMS through 3.22.0 contains a missing authorization vulnerability that allows authenticated users holding the Author or Editor role t
CVSS
6.5
Medio
EPSS
—
KEV
—
Exploit Today
0
0-100
Publicado: 25 sept 2026 · Última mod.: 25 sept 2026 · CWE-862
Sin historial EPSS suficiente todavía.
Bludit CMS through 3.22.0 contains a missing authorization vulnerability that allows authenticated users holding the Author or Editor role to read the full content of private drafts and scheduled posts belonging to any other user, including administrators, by exploiting the content-get-list AJAX endpoint in bl-kernel/ajax/content-get-list.php. Attackers can send an authenticated GET request to the admin AJAX endpoint with the draft parameter set to true, triggering getList() without ownership constraints and returning serialized page objects site-wide, exposing pre-publication material and sensitive notes stored in administrator-owned drafts.
CVECVSSEPSSKEVRExplotTítuloVis.
CVE-2026-95835——
——0Missing Authorization in the askpass escape code handler in kitty from 0.25.0 before 0.49.0 allows a local user other than the one running the terminal to obtain the text typed into a prompt that kitty itself displays, because handle_remote_askpass() in kitty/window.py opens the POSIX shared memory object named in the escape code, parses a prompt definition out of it, and writes the user's answer back into an object of that same name, without at any point checking that the object is owned by the user running kitty or that its permissions exclude other users. The equivalent consumer of the same SharedMemory class in the ssh kitten performs exactly that check; the askpass path did not. The handler is reached through a device control string processed from the byte stream of the window, so the attacker must also cause bytes of their choosing to be displayed by the victim's terminal. Where the POSIX shared memory namespace is shared between the two users, a second local user can create an object with permissions that allow the victim to read and write it, cause the victim's kitty to render a prompt of the attacker's choosing, including a masked password prompt, and read the typed secret back out of the object afterwards. The prompt text is additionally passed to the display without control character sanitisation, so it can overwrite the warning line kitty prints above it. The answer is written by reopening an object of that name when the user answers, rather than through the handle already held. This results in disclosure of a secret typed by the victim to a second local user, and does not require any privilege on the victim's account.1hCVE-2026-933644.3 MED—
——0Bludit CMS through 3.22.0 contains a mass assignment vulnerability that allows authenticated users with the Author role to modify privileged page fields reserved for administrators by injecting reserved parameters into a content save request. Attackers can submit reserved fields such as type and username through the Pages::edit() function in bl-kernel/pages.class.php, which iterates all fields declared in dbFields without per-field authorization, enabling an Author to convert pages to static site-wide navigation entries or transfer page ownership to arbitrary accounts.1hCVE-2026-933634.3 MED—
——0The @payloadcms/storage-vercel-blob storage adapter for Payload contains an improper access control vulnerability that allows authenticated users to bypass collection-level permissions by accessing the client-upload route directly. Attackers can upload files through the client-upload endpoint without possessing the required collection access permissions, circumventing the intended access control enforcement.1hCVE-2026-80432——
——0Missing Authorization in the drop handling path of the drag and drop protocol in kitty from 0.47.0 before 0.49.0 allows a program writing to the terminal to obtain the contents of files dragged over the window even when the user never completes the drop, because drop_enqueue_request() in kitty/dnd.c serves a drag data request without first checking the drop state of the window, so a client that issues the request while a drag is merely hovering receives the data offered for the drag. In the same file, drop_left_child(), which runs when the drag leaves the window without a drop having occurred, releases the offered MIME list but retains the pending request state, the open file descriptor and its main loop transfer timer, the directory handles, the URI list and the pending MIME name, so a client can continue to read through a retained directory handle, and an in-flight file transfer continues to stream, when no drag is in progress. The file contents are read from the filesystem by the kitty process itself using the paths the drag source offered. This results in disclosure of the contents of files the user moved over the window without ever releasing them into it.1hCVE-2026-67421——
——0RabbitMQ is a messaging and streaming broker. From 3.13.0 until 3.13.19, 4.0.24, 4.1.15, 4.2.10, and 4.3.5, RabbitMQ Management rendered an AMQP authorization-error reason containing an attacker-controlled queue name as HTML when the OAuth management UI was enabled. Exploitation requires an attacker with queue configure permission, a management administrator who can see but cannot read that queue, and the administrator clicking Get Message(s). A queue name containing a base element can then retarget the automatic relative refresh because the Content Security Policy omits base-uri and connect-src, and an attacker endpoint that permits the management origin through CORS can receive the victim's Authorization header. This issue is fixed in versions 3.13.19, 4.0.24, 4.1.15, 4.2.10, and 4.3.5.1hCVE-2026-67420——
——0RabbitMQ is a messaging and streaming broker. From 3.13.0 until 3.13.19, 4.0.24, 4.1.15, 4.2.10, and 4.3.5, RabbitMQ OAuth credential refresh retains revoked runtime tags. when an existing AMQP connection refreshes from an OAuth token that grants the impersonator tag to a valid same-username token that no longer grants that tag, RabbitMQ updates the OAuth backend implementation (token/scopes/expiry) but leaves the connection's runtime #user.tags unchanged. rabbitaccesscontrol:checkuserid/2 then still honors the stale impersonator tag, so the connection (including newly opened channels) can continue publishing messages with a foreign AMQP userid after that privilege should have been revoked. A fresh connection using the downgraded token correctly refuses the same publish, proving the defect is stale session state rather than the token Limited to connections that once held impersonator and successfully refresh to a downgraded same-username rabbitauthbackendoauth2 (or an equivalent refresh-capable backend that returns tags) is enabled for This issue is fixed in versions 3.13.19, 4.0.24, 4.1.15, 4.2.10, and 4.3.5.1h