🚨 CVE-2026-90926
Improper Control of Generation of Code ('Code Injection') vulnerability in Innotim Software, Telecommunications and Consultancy Trade Ltd. Co. Logsign SIEM allows Code Injection.
This issue affects Logsign SIEM: from 6.4.101 before 6.4.117.
🎖@cveNotify
Improper Control of Generation of Code ('Code Injection') vulnerability in Innotim Software, Telecommunications and Consultancy Trade Ltd. Co. Logsign SIEM allows Code Injection.
This issue affects Logsign SIEM: from 6.4.101 before 6.4.117.
🎖@cveNotify
siberguvenlik.gov.tr
T.C. Siber Güvenlik Başkanlığı
Türkiye Cumhuriyeti Cumhurbaşkanlığı Siber Güvenlik Başkanlığı resmi web sitesi.
🚨 CVE-2026-93537
A user who can supply bundle content to a repository referenced by a GitRepo resource, for example through Git push access, or through permission to create or modify a GitRepo, can cause SUSE Rancher Fleet to read files from the filesystem of the environment that processes the bundle and include their contents in the generated Bundle resource. This can expose configuration or credential material that the user has no Kubernetes RBAC permission to read, including Helm registry credentials made available to the bundle-processing job when per-path Helm credentials are configured.
This affects Fleet 0.16 before 0.16.2, 0.15 before 0.15.7, 0.14 before 0.14.11, 0.13 before 0.13.16, 0.12 before 0.12.20 and potentially older unsupported versions.
🎖@cveNotify
A user who can supply bundle content to a repository referenced by a GitRepo resource, for example through Git push access, or through permission to create or modify a GitRepo, can cause SUSE Rancher Fleet to read files from the filesystem of the environment that processes the bundle and include their contents in the generated Bundle resource. This can expose configuration or credential material that the user has no Kubernetes RBAC permission to read, including Helm registry credentials made available to the bundle-processing job when per-path Helm credentials are configured.
This affects Fleet 0.16 before 0.16.2, 0.15 before 0.15.7, 0.14 before 0.14.11, 0.13 before 0.13.16, 0.12 before 0.12.20 and potentially older unsupported versions.
🎖@cveNotify
GitHub
Path traversal in Fleet Helm valuesFiles allows disclosure of files outside the bundle directory
### Impact
A security vulnerability was discovered in Fleet's handling of the Helm `valuesFiles` setting in `fleet.yaml`. Entries in that list were not confined to the bundle directory, so a...
A security vulnerability was discovered in Fleet's handling of the Helm `valuesFiles` setting in `fleet.yaml`. Entries in that list were not confined to the bundle directory, so a...
🚨 CVE-2026-97335
Incorrect authorization in the custom storage volume creation endpoint in Canonical LXD versions 5.0.0 and later (fixed in 5.0.10, 5.21.8 and 6.10) on Linux allows an authenticated client with permission to create custom volumes in a project to copy, and so read, any custom storage volume from any other project on the server, including its snapshots and configuration. The client does this with a crafted request that sets a source volume and source.project but omits source.type.
🎖@cveNotify
Incorrect authorization in the custom storage volume creation endpoint in Canonical LXD versions 5.0.0 and later (fixed in 5.0.10, 5.21.8 and 6.10) on Linux allows an authenticated client with permission to create custom volumes in a project to copy, and so read, any custom storage volume from any other project on the server, including its snapshots and configuration. The client does this with a crafted request that sets a source volume and source.project but omits source.type.
🎖@cveNotify
GitHub
Project restriction bypass for custom volume copy with omitted source type
Reported from https://github.com/lxc/incus/security/advisories/GHSA-jh4v-j34r-2mgh
### Summary
Creating a custom storage volume with a `source` volume but no `source.type`
is handled as a co...
### Summary
Creating a custom storage volume with a `source` volume but no `source.type`
is handled as a co...
🚨 CVE-2025-20192
A vulnerability in the Internet Key Exchange version 1 (IKEv1) implementation of Cisco IOS XE Software could allow an authenticated, remote attacker to cause a denial of service (DoS) condition. The attacker must have valid IKEv1 VPN credentials to exploit this vulnerability.
This vulnerability is due to improper validation of IKEv1 phase 2 parameters before the IPsec security association creation request is handed off to the hardware cryptographic accelerator of an affected device. An attacker could exploit this vulnerability by sending crafted IKEv1 messages to the affected device. A successful exploit could allow the attacker to cause the device to reload.
🎖@cveNotify
A vulnerability in the Internet Key Exchange version 1 (IKEv1) implementation of Cisco IOS XE Software could allow an authenticated, remote attacker to cause a denial of service (DoS) condition. The attacker must have valid IKEv1 VPN credentials to exploit this vulnerability.
This vulnerability is due to improper validation of IKEv1 phase 2 parameters before the IPsec security association creation request is handed off to the hardware cryptographic accelerator of an affected device. An attacker could exploit this vulnerability by sending crafted IKEv1 messages to the affected device. A successful exploit could allow the attacker to cause the device to reload.
🎖@cveNotify
Cisco
Cisco Security Advisory: Cisco IOS XE Software Internet Key Exchange Version 1 Denial of Service Vulnerability
A vulnerability in the Internet Key Exchange version 1 (IKEv1) implementation of Cisco IOS XE Software could allow an authenticated, remote attacker to cause a denial of service (DoS) condition. The attacker must have valid IKEv1 VPN credentials to exploit…
🚨 CVE-2025-20315
A vulnerability in the Network-Based Application Recognition (NBAR) feature of Cisco IOS XE Software could allow an unauthenticated, remote attacker to cause an affected device to reload, causing a denial of service (DoS) condition.
This vulnerability is due to improper handling of malformed Control and Provisioning of Wireless Access Points (CAPWAP) packets. An attacker could exploit this vulnerability by sending malformed CAPWAP packets through an affected device. A successful exploit could allow the attacker to cause the device to reload unexpectedly, resulting in a DoS condition.
🎖@cveNotify
A vulnerability in the Network-Based Application Recognition (NBAR) feature of Cisco IOS XE Software could allow an unauthenticated, remote attacker to cause an affected device to reload, causing a denial of service (DoS) condition.
This vulnerability is due to improper handling of malformed Control and Provisioning of Wireless Access Points (CAPWAP) packets. An attacker could exploit this vulnerability by sending malformed CAPWAP packets through an affected device. A successful exploit could allow the attacker to cause the device to reload unexpectedly, resulting in a DoS condition.
🎖@cveNotify
Cisco
Cisco Security Advisory: Cisco IOS XE Software Network-Based Application Recognition Denial of Service Vulnerability
A vulnerability in the Network-Based Application Recognition (NBAR) feature of Cisco IOS XE Software could allow an unauthenticated, remote attacker to cause an affected device to reload, causing a denial of service (DoS) condition.
This vulnerability is…
This vulnerability is…
🚨 CVE-2026-77246
MCP Atlassian is a Model Context Protocol (MCP) server for Atlassian products (Confluence and Jira). Prior to 0.22.0, an HTTP transport deployment with READ_ONLY_MODE=false accepts a request without an Authorization identity and permits attacker-controlled Atlassian service headers, including X-Atlassian-Confluence-Url, to select a public attacker hostname or one allowed by MCP_ALLOWED_URL_DOMAINS. A caller can then invoke confluence_upload_attachment or the Jira attachment variant in src/mcp_atlassian/jira/attachments.py with a server-local file_path and cause the MCP process to send the file to the selected attachment endpoint. This issue is fixed in version 0.22.0.
🎖@cveNotify
MCP Atlassian is a Model Context Protocol (MCP) server for Atlassian products (Confluence and Jira). Prior to 0.22.0, an HTTP transport deployment with READ_ONLY_MODE=false accepts a request without an Authorization identity and permits attacker-controlled Atlassian service headers, including X-Atlassian-Confluence-Url, to select a public attacker hostname or one allowed by MCP_ALLOWED_URL_DOMAINS. A caller can then invoke confluence_upload_attachment or the Jira attachment variant in src/mcp_atlassian/jira/attachments.py with a server-local file_path and cause the MCP process to send the file to the selected attachment endpoint. This issue is fixed in version 0.22.0.
🎖@cveNotify
GitHub
Security hardening across attachment, transport, SSRF, authorization,… · sooperset/mcp-atlassian@b041733
… filter, and OAuth layers (#1448)
* test(security): add xfail-strict regression tests for advisory families
Reproduce known attack vectors and assert the secure outcome, marked
xfail(strict=True...
* test(security): add xfail-strict regression tests for advisory families
Reproduce known attack vectors and assert the secure outcome, marked
xfail(strict=True...
🚨 CVE-2026-77247
MCP Atlassian is a Model Context Protocol (MCP) server for Atlassian products (Confluence and Jira). Prior to 0.22.0, Jira and Confluence upload tools interpret caller-controlled path arguments on the MCP server and open those files before sending them as attachments. In remote or multi-user deployments, a permitted client can disclose host files without shell or direct filesystem access. The advisory traces the vulnerable input and processing flow through AttachmentsMixin.upload_attachment, AttachmentsMixin.upload_attachments, file_path, file_paths, and jira update_issue, which identify the affected entry points, controls, and code paths. This issue is fixed in version 0.22.0.
🎖@cveNotify
MCP Atlassian is a Model Context Protocol (MCP) server for Atlassian products (Confluence and Jira). Prior to 0.22.0, Jira and Confluence upload tools interpret caller-controlled path arguments on the MCP server and open those files before sending them as attachments. In remote or multi-user deployments, a permitted client can disclose host files without shell or direct filesystem access. The advisory traces the vulnerable input and processing flow through AttachmentsMixin.upload_attachment, AttachmentsMixin.upload_attachments, file_path, file_paths, and jira update_issue, which identify the affected entry points, controls, and code paths. This issue is fixed in version 0.22.0.
🎖@cveNotify
GitHub
Security hardening across attachment, transport, SSRF, authorization,… · sooperset/mcp-atlassian@b041733
… filter, and OAuth layers (#1448)
* test(security): add xfail-strict regression tests for advisory families
Reproduce known attack vectors and assert the secure outcome, marked
xfail(strict=True...
* test(security): add xfail-strict regression tests for advisory families
Reproduce known attack vectors and assert the secure outcome, marked
xfail(strict=True...
🚨 CVE-2026-67236
RabbitMQ is a messaging and streaming broker. From 4.2.0 until 4.2.8 and 4.3.2, a successful POST /login caused is_authorized/2 to set an auth cookie containing base64-encoded username:password credentials without HttpOnly, Secure, SameSite, or expiration protections. Because base64 is encoding rather than encryption, an attacker with same-origin cross-site scripting, an HTTP-readable network position, or local access to the browser cookie store could recover the actual login credentials; older browsers that treated an absent SameSite attribute as None also sent the cookie cross-site. This issue is fixed in versions 4.2.8 and 4.3.2.
🎖@cveNotify
RabbitMQ is a messaging and streaming broker. From 4.2.0 until 4.2.8 and 4.3.2, a successful POST /login caused is_authorized/2 to set an auth cookie containing base64-encoded username:password credentials without HttpOnly, Secure, SameSite, or expiration protections. Because base64 is encoding rather than encryption, an attacker with same-origin cross-site scripting, an HTTP-readable network position, or local access to the browser cookie store could recover the actual login credentials; older browsers that treated an absent SameSite attribute as None also sent the cookie cross-site. This issue is fixed in versions 4.2.8 and 4.3.2.
🎖@cveNotify
GitHub
Fix Plaintext credentials stored in an insecure cookie · rabbitmq/rabbitmq-server@df9e7f4
Remove dead-code that set the cookie
(cherry picked from commit 2622b0577e0ff55ee6b5b2f69fa546b4516f8241)
(cherry picked from commit edf1fbc7217aaf736955d2e13c9534901a2e0778)
(cherry picked from commit 2622b0577e0ff55ee6b5b2f69fa546b4516f8241)
(cherry picked from commit edf1fbc7217aaf736955d2e13c9534901a2e0778)
🚨 CVE-2026-56723
Zammad is a web based open source helpdesk/customer support system. Prior to 7.0.2, a customer who can view a ticket cannot see internal ticket articles through the article listing API. However, the same customer can directly request an attachment belonging to an internal article via the attachment download endpoint, bypassing article-level authorization. This results in an inconsistency: The article listing hides internal articles from customers. The attachment download only checks the parent ticket, not the article, so the same customer can download the attachment directly. This issue is fixed in version 7.0.2.
🎖@cveNotify
Zammad is a web based open source helpdesk/customer support system. Prior to 7.0.2, a customer who can view a ticket cannot see internal ticket articles through the article listing API. However, the same customer can directly request an attachment belonging to an internal article via the attachment download endpoint, bypassing article-level authorization. This results in an inconsistency: The article listing hides internal articles from customers. The attachment download only checks the parent ticket, not the article, so the same customer can download the attachment directly. This issue is fixed in version 7.0.2.
🎖@cveNotify
GitHub
Maintenance: Improve ticket attachment download endpoint. · zammad/zammad@e661d00
Zammad is a web based open source helpdesk/customer support system. - Maintenance: Improve ticket attachment download endpoint. · zammad/zammad@e661d00
🚨 CVE-2026-56724
Zammad is a web based open source helpdesk/customer support system. Prior to 7.0.2, summary An issue with permission checks in the knowledge base management area has been identified. Under certain conditions, data validation for linked items was not fully enforced. This could have allowed users with limited read permissions to interact with items outside their assigned access scope. Data access has been strengthened in the current version through additional validation routines. This issue is fixed in version 7.0.2.
🎖@cveNotify
Zammad is a web based open source helpdesk/customer support system. Prior to 7.0.2, summary An issue with permission checks in the knowledge base management area has been identified. Under certain conditions, data validation for linked items was not fully enforced. This could have allowed users with limited read permissions to interact with items outside their assigned access scope. Data access has been strengthened in the current version through additional validation routines. This issue is fixed in version 7.0.2.
🎖@cveNotify
GitHub
Maintenance: Improve KB attachments handling · zammad/zammad@13ccc13
Zammad is a web based open source helpdesk/customer support system. - Maintenance: Improve KB attachments handling · zammad/zammad@13ccc13
🚨 CVE-2026-56729
Zammad is a web based open source helpdesk/customer support system. Prior to 7.0.2, when multiple KB categories have different editor roles assigned, a user with knowledge_base.editor in one category can see answer titles and updated_at timestamps from categories they do not have editor access to , via the global quick search. Category names are not leaked, and opening the answer returns "Page not found," but the title alone may disclose sensitive information. This vulnerability is fixed in 7.0.2.
🎖@cveNotify
Zammad is a web based open source helpdesk/customer support system. Prior to 7.0.2, when multiple KB categories have different editor roles assigned, a user with knowledge_base.editor in one category can see answer titles and updated_at timestamps from categories they do not have editor access to , via the global quick search. Category names are not leaked, and opening the answer returns "Page not found," but the title alone may disclose sensitive information. This vulnerability is fixed in 7.0.2.
🎖@cveNotify
GitHub
Maintenance: Improve Knowledge Base search when using granular permis… · zammad/zammad@5076aa1
…sions
🚨 CVE-2026-61837
RabbitMQ is a messaging and streaming broker. From 4.0.0 until 4.3.3, 4.2.9, 4.1.14, and 4.0.23, AMQP 1.0 management GET /bindings exposes full binding topology to any authenticated AMQP user without resource/management permission checks. the AMQP 1.0 HTTP-over-AMQP management endpoint GET /bindings (the rabbitamqpmanagement handler) enumerates bindings between an arbitrary source exchange and destination queue/exchange in the caller's virtual host without performing any resource-level permission check. Unlike every sibling operation in the same module (which call checkresourceaccess / bindingchecks), the GET handler ignores the authenticated User and returns the binding list unchanged. As a result, any authenticated AMQP 1.0 client that can open a management link pair , including users with no management/monitoring/policymaker/administrator tag , can enumerate the complete binding topology (source exchanges, destination queues/exchanges, routing keys, and binding arguments) of the virtual host they can access. The equivalent HTTP management API (GET /api/bindings) Confidentiality impact: a non-management AMQP 1.0 user can enumerate the complete routing topology of any virtual host it can connect to , every (source exchange, destination queue/exchange, routing key, binding arguments) This issue is fixed in versions 4.3.3, 4.2.9, 4.1.14, and 4.0.23.
🎖@cveNotify
RabbitMQ is a messaging and streaming broker. From 4.0.0 until 4.3.3, 4.2.9, 4.1.14, and 4.0.23, AMQP 1.0 management GET /bindings exposes full binding topology to any authenticated AMQP user without resource/management permission checks. the AMQP 1.0 HTTP-over-AMQP management endpoint GET /bindings (the rabbitamqpmanagement handler) enumerates bindings between an arbitrary source exchange and destination queue/exchange in the caller's virtual host without performing any resource-level permission check. Unlike every sibling operation in the same module (which call checkresourceaccess / bindingchecks), the GET handler ignores the authenticated User and returns the binding list unchanged. As a result, any authenticated AMQP 1.0 client that can open a management link pair , including users with no management/monitoring/policymaker/administrator tag , can enumerate the complete binding topology (source exchanges, destination queues/exchanges, routing keys, and binding arguments) of the virtual host they can access. The equivalent HTTP management API (GET /api/bindings) Confidentiality impact: a non-management AMQP 1.0 user can enumerate the complete routing topology of any virtual host it can connect to , every (source exchange, destination queue/exchange, routing key, binding arguments) This issue is fixed in versions 4.3.3, 4.2.9, 4.1.14, and 4.0.23.
🎖@cveNotify
GitHub
AMQP 1.0 management: align `GET /bindings` with the rest of the bindi… · rabbitmq/rabbitmq-server@341e3f2
…ngs handlers
(cherry picked from commit 93998ec20bb7444d8f65a450b5a0f9ab9b104788)
(cherry picked from commit 93998ec20bb7444d8f65a450b5a0f9ab9b104788)
🚨 CVE-2026-66071
RabbitMQ is a messaging and streaming broker. From 3.13.0 until 3.13.15 and 4.0.22 and 4.1.11 and 4.2.6 and 4.3.1, Atom exhaustion: OAuth2 JWT tag: scope values. extractscopes/1 parses scopes of the form .tag: and calls rabbitdatacoercion:toatom() to convert to a tag atom. The token signature is verified first, so the attacker cannot forge scopes , but in IdP configurations where scope content is user-influenced, each login with a novel tag value leaks one In deployments where users can influence the scopes included in their IdP-issued JWT rabbitmqauthbackendoauth2 enabled IdP permits attacker-influenced scope values in signed tokens. This issue is fixed in versions 3.13.15 and 4.0.22 and 4.1.11 and 4.2.6 and 4.3.1.
🎖@cveNotify
RabbitMQ is a messaging and streaming broker. From 3.13.0 until 3.13.15 and 4.0.22 and 4.1.11 and 4.2.6 and 4.3.1, Atom exhaustion: OAuth2 JWT tag: scope values. extractscopes/1 parses scopes of the form .tag: and calls rabbitdatacoercion:toatom() to convert to a tag atom. The token signature is verified first, so the attacker cannot forge scopes , but in IdP configurations where scope content is user-influenced, each login with a novel tag value leaks one In deployments where users can influence the scopes included in their IdP-issued JWT rabbitmqauthbackendoauth2 enabled IdP permits attacker-influenced scope values in signed tokens. This issue is fixed in versions 3.13.15 and 4.0.22 and 4.1.11 and 4.2.6 and 4.3.1.
🎖@cveNotify
GitHub
OAuth 2: limit the number of scopes allowed on JWT tokens · rabbitmq/rabbitmq-server@9a44124
There are known examples of hundreds of scopes, so
set the limit to 2048.
(cherry picked from commit b1f5600cf11662593d77380c6368c160e2e758dc)
(cherry picked from commit c5690583a53789a3bf00cca508...
set the limit to 2048.
(cherry picked from commit b1f5600cf11662593d77380c6368c160e2e758dc)
(cherry picked from commit c5690583a53789a3bf00cca508...
🚨 CVE-2026-66073
RabbitMQ is a messaging and streaming broker. From 3.13.0 until 3.13.15 and 4.0.20 and 4.1.11 and 4.2.6, Atom table exhaustion via management API node field. pUT /api/queues/:vhost/:name (and the exchanges and bindings endpoints) accepts a node JSON field. The value goes through rabbitnodes:make → listtoatom with no cluster membership check first. Each unique value permanently leaks one atom. A March 2026 refactoring (ea61ce2563) introduced safe helpers in rabbitmgmtnodes.erl (parsenodename, safeatom, and requirenodename, using binarytoexistingatom) and fixed several callers (QQ replica ops, wmauthattempts, wmnodememoryets, getsortreverse, and rabbitfederationmgmt), but getnode/1 in rabbitmgmtutil.erl:880-885, the primary vector used by directrequest/6, was not Roughly 900K requests crash the VM via systemlimit, and all tenants lose Any user with the management tag and one vhost, the lowest privilege This issue is fixed in versions 3.13.15 and 4.0.20 and 4.1.11 and 4.2.6.
🎖@cveNotify
RabbitMQ is a messaging and streaming broker. From 3.13.0 until 3.13.15 and 4.0.20 and 4.1.11 and 4.2.6, Atom table exhaustion via management API node field. pUT /api/queues/:vhost/:name (and the exchanges and bindings endpoints) accepts a node JSON field. The value goes through rabbitnodes:make → listtoatom with no cluster membership check first. Each unique value permanently leaks one atom. A March 2026 refactoring (ea61ce2563) introduced safe helpers in rabbitmgmtnodes.erl (parsenodename, safeatom, and requirenodename, using binarytoexistingatom) and fixed several callers (QQ replica ops, wmauthattempts, wmnodememoryets, getsortreverse, and rabbitfederationmgmt), but getnode/1 in rabbitmgmtutil.erl:880-885, the primary vector used by directrequest/6, was not Roughly 900K requests crash the VM via systemlimit, and all tenants lose Any user with the management tag and one vhost, the lowest privilege This issue is fixed in versions 3.13.15 and 4.0.20 and 4.1.11 and 4.2.6.
🎖@cveNotify
GitHub
Address atom exhaustion attack · rabbitmq/rabbitmq-server@7f64311
(cherry picked from commit ca36babb7c169c451ded51408c86673e9a312363)
(cherry picked from commit 150bee6c33da57bce107fc373d20247003f07ed1)
(cherry picked from commit 150bee6c33da57bce107fc373d20247003f07ed1)
🚨 CVE-2026-66078
RabbitMQ is a messaging and streaming broker. From 3.13.0 until 3.13.15 and 4.0.20 and 4.1.11 and 4.2.6, protected tag bypass via bulk-delete. dELETE /api/users/:name refuses to delete users tagged protected (rabbitmgmtwmuser:deleteresource/2 checks isprotecteduser). POST /api/users/bulk-delete iterates the supplied username list and calls rabbitauthbackendinternal:deleteuser/2 directly , that function has no protected-tag check , so the guard is silently An administrator can delete protected-tagged service accounts via the bulk endpoint, bypassing a safeguard the test suite confirms is rabbitmqmanagement enabled Attacker has the administrator tag A protected-tagged user. This issue is fixed in versions 3.13.15 and 4.0.20 and 4.1.11 and 4.2.6.
🎖@cveNotify
RabbitMQ is a messaging and streaming broker. From 3.13.0 until 3.13.15 and 4.0.20 and 4.1.11 and 4.2.6, protected tag bypass via bulk-delete. dELETE /api/users/:name refuses to delete users tagged protected (rabbitmgmtwmuser:deleteresource/2 checks isprotecteduser). POST /api/users/bulk-delete iterates the supplied username list and calls rabbitauthbackendinternal:deleteuser/2 directly , that function has no protected-tag check , so the guard is silently An administrator can delete protected-tagged service accounts via the bulk endpoint, bypassing a safeguard the test suite confirms is rabbitmqmanagement enabled Attacker has the administrator tag A protected-tagged user. This issue is fixed in versions 3.13.15 and 4.0.20 and 4.1.11 and 4.2.6.
🎖@cveNotify
GitHub
Use `is_protected_user/1` in one more place · rabbitmq/rabbitmq-server@e5b890a
(cherry picked from commit 0046a4d492296e841e6cd0f40c9e5c743db34800)
(cherry picked from commit db8ec82457151be40924d669bb5f27a00e433801)
(cherry picked from commit db8ec82457151be40924d669bb5f27a00e433801)
🚨 CVE-2026-67222
RabbitMQ is a messaging and streaming broker. From 3.13.0 until 3.13.15, 4.0.20, 4.1.11, and 4.2.6, mechanisms/1 applied list_to_atom/1 to every colon-delimited token in an attacker-controlled auth_mechanism value, permanently consuming Erlang VM atoms and allowing the node to be crashed with a large request. Exploitation requires the Shovel or Federation plugin to be in use, and setting auth_mechanism requires the policymaker tag. This issue is fixed in versions 3.13.15, 4.0.20, 4.1.11, and 4.2.6.
🎖@cveNotify
RabbitMQ is a messaging and streaming broker. From 3.13.0 until 3.13.15, 4.0.20, 4.1.11, and 4.2.6, mechanisms/1 applied list_to_atom/1 to every colon-delimited token in an attacker-controlled auth_mechanism value, permanently consuming Erlang VM atoms and allowing the node to be crashed with a large request. Exploitation requires the Shovel or Federation plugin to be in use, and setting auth_mechanism requires the policymaker tag. This issue is fixed in versions 3.13.15, 4.0.20, 4.1.11, and 4.2.6.
🎖@cveNotify
GitHub
Release RabbitMQ 4.2.6 · rabbitmq/rabbitmq-server
RabbitMQ 4.2.6 is a maintenance release in the 4.2.x release series.
It is strongly recommended that you read 4.2.0 release notes
in detail if upgrading from a version prior to 4.2.0.
Minimum Suppo...
It is strongly recommended that you read 4.2.0 release notes
in detail if upgrading from a version prior to 4.2.0.
Minimum Suppo...
🚨 CVE-2026-67223
RabbitMQ is a messaging and streaming broker. The advisory establishes affected 3.13, 4.0, 4.1, 4.2, and 4.3 maintenance lines but contains conflicting first-fixed versions for the 3.13, 4.0, and 4.1 lines. fill/2 substitutes ${username} into user_dn_pattern without RFC 4514 DN escaping, allowing a crafted username to alter the LDAP bind DN and potentially select a different directory entry. Exploitation requires rabbitmq_auth_backend_ldap with a user_dn_pattern containing ${username}, a directory layout in which the injected suffix resolves usefully, and a password valid for the resulting DN. The advisory body identifies 3.13.15, 4.0.20, 4.1.11, 4.2.9, and 4.3.3 as fixed, while structured metadata identifies 3.13.18, 4.0.23, 4.1.14, 4.2.9, and 4.3.3. No fixed-version assertion is certifiable until a curator resolves this conflict.
🎖@cveNotify
RabbitMQ is a messaging and streaming broker. The advisory establishes affected 3.13, 4.0, 4.1, 4.2, and 4.3 maintenance lines but contains conflicting first-fixed versions for the 3.13, 4.0, and 4.1 lines. fill/2 substitutes ${username} into user_dn_pattern without RFC 4514 DN escaping, allowing a crafted username to alter the LDAP bind DN and potentially select a different directory entry. Exploitation requires rabbitmq_auth_backend_ldap with a user_dn_pattern containing ${username}, a directory layout in which the injected suffix resolves usefully, and a password valid for the resulting DN. The advisory body identifies 3.13.15, 4.0.20, 4.1.11, 4.2.9, and 4.3.3 as fixed, while structured metadata identifies 3.13.18, 4.0.23, 4.1.14, 4.2.9, and 4.3.3. No fixed-version assertion is certifiable until a curator resolves this conflict.
🎖@cveNotify
GitHub
LDAP: handle DN template values per RFC 4514 · rabbitmq/rabbitmq-server@ad3ca47
(cherry picked from commit 9a3c55a55979a72c755b02c50b4553e90c61f425)
🚨 CVE-2026-67225
RabbitMQ is a messaging and streaming broker. From 3.13.0 until 3.13.15, 4.0.20, 4.1.11, and 4.2.6, the stream protocol stored the FrameMax value negotiated during the Tune handshake but did not compare it with an inbound frame's declared length before buffering the frame. With the stream plugin enabled, a remote client could therefore cause excessive memory pressure and denial of service by declaring an oversized frame. This issue is fixed in versions 3.13.15, 4.0.20, 4.1.11, and 4.2.6.
🎖@cveNotify
RabbitMQ is a messaging and streaming broker. From 3.13.0 until 3.13.15, 4.0.20, 4.1.11, and 4.2.6, the stream protocol stored the FrameMax value negotiated during the Tune handshake but did not compare it with an inbound frame's declared length before buffering the frame. With the stream plugin enabled, a remote client could therefore cause excessive memory pressure and denial of service by declaring an oversized frame. This issue is fixed in versions 3.13.15, 4.0.20, 4.1.11, and 4.2.6.
🎖@cveNotify
GitHub
Release RabbitMQ 4.2.6 · rabbitmq/rabbitmq-server
RabbitMQ 4.2.6 is a maintenance release in the 4.2.x release series.
It is strongly recommended that you read 4.2.0 release notes
in detail if upgrading from a version prior to 4.2.0.
Minimum Suppo...
It is strongly recommended that you read 4.2.0 release notes
in detail if upgrading from a version prior to 4.2.0.
Minimum Suppo...
🚨 CVE-2026-67226
RabbitMQ is a messaging and streaming broker. From 4.0.0 until 4.0.22 and 4.1.14 and 4.2.7, Admin-only atom exhaustion: PUT /api/users tags list. settags/2 maps rabbitdatacoercion:toatom/1 over the user's tags list. The 20 MB management body limit fits ~3-4M short tag strings. An administrator can crash the node in a single request by creating a user (or importing definitions) with ~1M unique tag administrator. This issue is fixed in versions 4.0.22 and 4.1.14 and 4.2.7.
🎖@cveNotify
RabbitMQ is a messaging and streaming broker. From 4.0.0 until 4.0.22 and 4.1.14 and 4.2.7, Admin-only atom exhaustion: PUT /api/users tags list. settags/2 maps rabbitdatacoercion:toatom/1 over the user's tags list. The 20 MB management body limit fits ~3-4M short tag strings. An administrator can crash the node in a single request by creating a user (or importing definitions) with ~1M unique tag administrator. This issue is fixed in versions 4.0.22 and 4.1.14 and 4.2.7.
🎖@cveNotify
GitHub
Limit the number of user tags to 3 · rabbitmq/rabbitmq-server@86601c5
The most common case is zero to two tags, so 32
is generous and should cover the cases with
a fair number of tags.
(cherry picked from commit 01a436d255f7f883ce8e4c266fb3dfd3d16c72df)
(cherry pick...
is generous and should cover the cases with
a fair number of tags.
(cherry picked from commit 01a436d255f7f883ce8e4c266fb3dfd3d16c72df)
(cherry pick...
🚨 CVE-2026-67227
RabbitMQ is a messaging and streaming broker. From 4.0.0 until 4.0.22 and 4.1.14 and 4.2.7 and 4.3.1, Atom exhaustion: toatom on global-parameter :name. resourceexists/2 (and the PUT/DELETE handlers) call rabbitdatacoercion:toatom/1 on the :name URL path segment. toatom/1 uses binarytoatom/2 (unsafe). The endpoint requires policymaker (not management, but below A user with the policymaker tag can crash the node by exhausting the atom table via repeated requests to /api/global-parameters/:name with unique :name Management plugin enabled policymaker tag ~1M HTTP. This issue is fixed in versions 4.0.22 and 4.1.14 and 4.2.7 and 4.3.1.
🎖@cveNotify
RabbitMQ is a messaging and streaming broker. From 4.0.0 until 4.0.22 and 4.1.14 and 4.2.7 and 4.3.1, Atom exhaustion: toatom on global-parameter :name. resourceexists/2 (and the PUT/DELETE handlers) call rabbitdatacoercion:toatom/1 on the :name URL path segment. toatom/1 uses binarytoatom/2 (unsafe). The endpoint requires policymaker (not management, but below A user with the policymaker tag can crash the node by exhausting the atom table via repeated requests to /api/global-parameters/:name with unique :name Management plugin enabled policymaker tag ~1M HTTP. This issue is fixed in versions 4.0.22 and 4.1.14 and 4.2.7 and 4.3.1.
🎖@cveNotify
GitHub
HTTP API: refactor global parameter name lookups · rabbitmq/rabbitmq-server@8fbe6d8
(cherry picked from commit b92b642d1eb73dae7727b1f677683fd3acf8d0d5)
🚨 CVE-2026-67230
RabbitMQ is a messaging and streaming broker. From 3.13.0 until 3.13.15, 4.0.20, 4.1.11, and 4.2.6, the Web STOMP WebSocket handler enforced neither max_frame_size nor login_timeout before authentication, allowing an unauthenticated client to keep a connection alive with a slow stream of small frames and accumulate unbounded pre-authentication state. The rabbitmq_web_stomp plugin must be enabled, and no authentication is required to reach the vulnerable path. This issue is fixed in versions 3.13.15, 4.0.20, 4.1.11, and 4.2.6.
🎖@cveNotify
RabbitMQ is a messaging and streaming broker. From 3.13.0 until 3.13.15, 4.0.20, 4.1.11, and 4.2.6, the Web STOMP WebSocket handler enforced neither max_frame_size nor login_timeout before authentication, allowing an unauthenticated client to keep a connection alive with a slow stream of small frames and accumulate unbounded pre-authentication state. The rabbitmq_web_stomp plugin must be enabled, and no authentication is required to reach the vulnerable path. This issue is fixed in versions 3.13.15, 4.0.20, 4.1.11, and 4.2.6.
🎖@cveNotify
GitHub
Web MQTT, Web STOMP: enforce login timeout for WebSocket connections · rabbitmq/rabbitmq-server@0b4080f
(cherry picked from commit f4fff6c87a357ec73eee3f83e72e0a54582d044f)
(cherry picked from commit 3ff40e40817e11b4504854f7c1ebbd2b507803c5)
(cherry picked from commit 3ff40e40817e11b4504854f7c1ebbd2b507803c5)