๐จ CVE-2026-61397
Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Apache CloudStack's OAuth2 authentication plugin and Google OAuth integration.
This issue affects Apache CloudStack: from 4.19.0.0 through 4.20.3.0 and from 4.21.0.0 through 4.22.1.0.
Users are recommended to upgrade to version 4.20.3.1 or 4.22.1.1, which fixes the issue.
๐@cveNotify
Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Apache CloudStack's OAuth2 authentication plugin and Google OAuth integration.
This issue affects Apache CloudStack: from 4.19.0.0 through 4.20.3.0 and from 4.21.0.0 through 4.22.1.0.
Users are recommended to upgrade to version 4.20.3.1 or 4.22.1.1, which fixes the issue.
๐@cveNotify
๐จ CVE-2026-61398
Improper Encoding or Escaping of Output vulnerability in Apache CloudStack's UI while using Instance Reset Password functionality.
This issue affects Apache CloudStack: from 4.15.1.0 through 4.20.3.0 and from 4.21.0.0 through 4.22.1.0.
Users are recommended to upgrade to version 4.20.3.1 or 4.22.1.1 or later, which fixes the issue.
๐@cveNotify
Improper Encoding or Escaping of Output vulnerability in Apache CloudStack's UI while using Instance Reset Password functionality.
This issue affects Apache CloudStack: from 4.15.1.0 through 4.20.3.0 and from 4.21.0.0 through 4.22.1.0.
Users are recommended to upgrade to version 4.20.3.1 or 4.22.1.1 or later, which fixes the issue.
๐@cveNotify
๐จ CVE-2026-61399
Improper Encoding or Escaping of Output vulnerability in Apache CloudStack's UI while using Lock User Functionality.
This issue affects Apache CloudStack: from 4.20.0.0 through 4.20.3.0 and from 4.21.0.0 through 4.22.1.0.
Users are recommended to upgrade to version 4.20.3.1 or 4.22.1.1 or later, which fixes the issue.
๐@cveNotify
Improper Encoding or Escaping of Output vulnerability in Apache CloudStack's UI while using Lock User Functionality.
This issue affects Apache CloudStack: from 4.20.0.0 through 4.20.3.0 and from 4.21.0.0 through 4.22.1.0.
Users are recommended to upgrade to version 4.20.3.1 or 4.22.1.1 or later, which fixes the issue.
๐@cveNotify
๐จ CVE-2026-61400
Improper Neutralization of Special Elements used in a Command ('Command Injection') vulnerability in Apache CloudStack's run and get diagnostics functionality for the system VMs and virtual routers.
An authenticated user holding the permissions required to invoke either `getDiagnosticsData` or `runDiagnostics` can achieve arbitrary command execution on the system VM and/or Virtual Router instances, with commands running as root (or as the diagnostics-process user, at minimum). This represents a full compromise of the affected instance and, depending on network segmentation, may provide a foothold for lateral movement within the CloudStack-managed infrastructure, including access to guest network traffic handled by the compromised Virtual Router.
The getDiagnosticsData and runDiagnostics APIs are restricted to only Admin role accounts by default.
This issue affects Apache CloudStack: from 4.20.0.0 through 4.20.3.0 and from 4.21.0.0 through 4.22.1.0.
Users are recommended to upgrade to version 4.20.3.1 or 4.22.1.1 or later, which fixes the issue.
๐@cveNotify
Improper Neutralization of Special Elements used in a Command ('Command Injection') vulnerability in Apache CloudStack's run and get diagnostics functionality for the system VMs and virtual routers.
An authenticated user holding the permissions required to invoke either `getDiagnosticsData` or `runDiagnostics` can achieve arbitrary command execution on the system VM and/or Virtual Router instances, with commands running as root (or as the diagnostics-process user, at minimum). This represents a full compromise of the affected instance and, depending on network segmentation, may provide a foothold for lateral movement within the CloudStack-managed infrastructure, including access to guest network traffic handled by the compromised Virtual Router.
The getDiagnosticsData and runDiagnostics APIs are restricted to only Admin role accounts by default.
This issue affects Apache CloudStack: from 4.20.0.0 through 4.20.3.0 and from 4.21.0.0 through 4.22.1.0.
Users are recommended to upgrade to version 4.20.3.1 or 4.22.1.1 or later, which fixes the issue.
๐@cveNotify
๐จ CVE-2026-61422
Authenticated pre-validation SSRF vulnerability in Apache CloudStack's template and ISO registration functionality.
When registering a template or ISO, CloudStack makes a live HTTP HEAD/GET call to determine file size for secondary storage usage-limit checks, and this happens before URL validation is performed. However, this does not pose a malicious template or ISO registration risk, as URL validation still occurs prior to the actual download by the Secondary Storage VM.This issue affects Apache CloudStack: in 4.20.3.0 and from 4.21.0.0 through 4.22.1.0.
Users are recommended to upgrade to version 4.20.3.1 or 4.22.1.1 or later, which fixes the issue.
๐@cveNotify
Authenticated pre-validation SSRF vulnerability in Apache CloudStack's template and ISO registration functionality.
When registering a template or ISO, CloudStack makes a live HTTP HEAD/GET call to determine file size for secondary storage usage-limit checks, and this happens before URL validation is performed. However, this does not pose a malicious template or ISO registration risk, as URL validation still occurs prior to the actual download by the Secondary Storage VM.This issue affects Apache CloudStack: in 4.20.3.0 and from 4.21.0.0 through 4.22.1.0.
Users are recommended to upgrade to version 4.20.3.1 or 4.22.1.1 or later, which fixes the issue.
๐@cveNotify
๐จ CVE-2026-62440
Improper Access Control vulnerability in Apache CloudStack's Kubernetes Service (CKS) plugin, allowing cross-tenant manipulation of the Kubernetes cluster while adding and removing nodes.
This issue affects Apache CloudStack: from 4.21.0.0 through 4.22.1.0.
Users are recommended to upgrade to version 4.22.1.1 or later, which fixes the issue.
๐@cveNotify
Improper Access Control vulnerability in Apache CloudStack's Kubernetes Service (CKS) plugin, allowing cross-tenant manipulation of the Kubernetes cluster while adding and removing nodes.
This issue affects Apache CloudStack: from 4.21.0.0 through 4.22.1.0.
Users are recommended to upgrade to version 4.22.1.1 or later, which fixes the issue.
๐@cveNotify
๐จ CVE-2026-63046
Improper Neutralization of Argument Delimiters in a Command ('Argument Injection') vulnerability in Apache InLong. Agent Installer's ModuleManager executes arbitrary shell
commands via ExcuteLinux.exeCmd() with no filtering or whitelist
validation.
This issue affects Apache InLong: from 2.0.0 before 2.4.0.
Users are advised to upgrade to Apache InLong's 2.4.0 or cherry-pick [1]/[2] to solve it.
[1] https://github.com/apache/inlong/pull/12151 .
[2] https://github.com/apache/inlong/pull/12155 .
๐@cveNotify
Improper Neutralization of Argument Delimiters in a Command ('Argument Injection') vulnerability in Apache InLong. Agent Installer's ModuleManager executes arbitrary shell
commands via ExcuteLinux.exeCmd() with no filtering or whitelist
validation.
This issue affects Apache InLong: from 2.0.0 before 2.4.0.
Users are advised to upgrade to Apache InLong's 2.4.0 or cherry-pick [1]/[2] to solve it.
[1] https://github.com/apache/inlong/pull/12151 .
[2] https://github.com/apache/inlong/pull/12155 .
๐@cveNotify
๐จ CVE-2026-65613
Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Apache CloudStack's Webhook module while listing and deleting deliveries.
This issue affects Apache CloudStack: from 4.20.0.0 through 4.20.3.0 and from 4.21.0.0 through 4.22.1.0.
Users are recommended to upgrade to version 4.20.3.1 or 4.22.1.1 or later, which fixes the issue.
๐@cveNotify
Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Apache CloudStack's Webhook module while listing and deleting deliveries.
This issue affects Apache CloudStack: from 4.20.0.0 through 4.20.3.0 and from 4.21.0.0 through 4.22.1.0.
Users are recommended to upgrade to version 4.20.3.1 or 4.22.1.1 or later, which fixes the issue.
๐@cveNotify
๐จ CVE-2026-66721
Missing authorization issue for domain admins in CloudStack's host tags listing functionality.
Domain Admins, by default, have permission to call the listHostTags API, but the API returns host tags for every host in the environment without domain scoping. It should instead be restricted to only the hosts dedicated to that admin's domain.
This issue affects Apache CloudStack: from 4.12.0.0 through 4.20.3.0 and from 4.21.0.0 through 4.22.1.0.
Users are recommended to upgrade to version 4.20.3.1 or 4.22.1.1 or later, which fixes the issue.
๐@cveNotify
Missing authorization issue for domain admins in CloudStack's host tags listing functionality.
Domain Admins, by default, have permission to call the listHostTags API, but the API returns host tags for every host in the environment without domain scoping. It should instead be restricted to only the hosts dedicated to that admin's domain.
This issue affects Apache CloudStack: from 4.12.0.0 through 4.20.3.0 and from 4.21.0.0 through 4.22.1.0.
Users are recommended to upgrade to version 4.20.3.1 or 4.22.1.1 or later, which fixes the issue.
๐@cveNotify
๐จ CVE-2026-66797
Improper access control in CloudStack's annotation functionality allows unauthorized comment creation and disclosure.
The addAnnotation and listAnnotation APIs perform an ownership check when an entity's UUID is specified, but fail to honor its result correctly. This lets any authenticated user write annotations to, and disclose existing annotations/comments on, an entity they don't own by simply supplying its UUID.
This issue affects Apache CloudStack: from 4.15.0.0 through 4.20.3.0 and from 4.21.0.0 through 4.22.1.0.
Users are recommended to upgrade to version 4.20.3.1 or 4.22.1.1 or later, which fixes the issue.
๐@cveNotify
Improper access control in CloudStack's annotation functionality allows unauthorized comment creation and disclosure.
The addAnnotation and listAnnotation APIs perform an ownership check when an entity's UUID is specified, but fail to honor its result correctly. This lets any authenticated user write annotations to, and disclose existing annotations/comments on, an entity they don't own by simply supplying its UUID.
This issue affects Apache CloudStack: from 4.15.0.0 through 4.20.3.0 and from 4.21.0.0 through 4.22.1.0.
Users are recommended to upgrade to version 4.20.3.1 or 4.22.1.1 or later, which fixes the issue.
๐@cveNotify
๐จ CVE-2026-68745
Certificate validation failures in SAML authentication in Apache CloudStack 4.20.3.0 and 4.22.1.0 on all platforms allow a malicious agent to forge a SAML response to the management server. The agent will have to spoof the ip address of the IdP or get an url of its own choosing registered in the management server, after which it can allow logging on with forged signatures.
Users are recommended to upgrade to versions 4.20.3.1 or 4.22.1.1 and above, which fix this issue.
๐@cveNotify
Certificate validation failures in SAML authentication in Apache CloudStack 4.20.3.0 and 4.22.1.0 on all platforms allow a malicious agent to forge a SAML response to the management server. The agent will have to spoof the ip address of the IdP or get an url of its own choosing registered in the management server, after which it can allow logging on with forged signatures.
Users are recommended to upgrade to versions 4.20.3.1 or 4.22.1.1 and above, which fix this issue.
๐@cveNotify
๐จ CVE-2026-74866
@fastify/busboy is a multipart form-data parser for Node.js. Its multipart part-header parser splits header lines only on the two-byte carriage-return line-feed sequence, so a lone carriage return or line feed embedded in a part header is not treated as a line break and is carried verbatim into the parsed Content-Disposition filename and field name handed to the application. An attacker who uploads a file whose filename or field name contains a bare carriage return or line feed can inject control characters into consumers that trust the parser to return clean values, enabling filesystem filename pollution, log forging, or header injection when the value is forwarded to a carriage-return-sensitive sink. All versions of @fastify/busboy up to and including 3.2.1 are affected. The issue is fixed in version 3.2.2, which rejects any header line that still contains a bare carriage return or line feed. Users should upgrade to 3.2.2, and consumers such as @fastify/multipart should bump their @fastify/busboy dependency to pull in the fix.
๐@cveNotify
@fastify/busboy is a multipart form-data parser for Node.js. Its multipart part-header parser splits header lines only on the two-byte carriage-return line-feed sequence, so a lone carriage return or line feed embedded in a part header is not treated as a line break and is carried verbatim into the parsed Content-Disposition filename and field name handed to the application. An attacker who uploads a file whose filename or field name contains a bare carriage return or line feed can inject control characters into consumers that trust the parser to return clean values, enabling filesystem filename pollution, log forging, or header injection when the value is forwarded to a carriage-return-sensitive sink. All versions of @fastify/busboy up to and including 3.2.1 are affected. The issue is fixed in version 3.2.2, which rejects any header line that still contains a bare carriage return or line feed. Users should upgrade to 3.2.2, and consumers such as @fastify/multipart should bump their @fastify/busboy dependency to pull in the fix.
๐@cveNotify
cna.openjsf.org
Security Advisories | OpenJS Foundation CVE Numbering Authority
The OpenJS Foundation's CVE Numbering Authority (CNA)
๐จ CVE-2026-77710
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.
๐@cveNotify
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.
๐@cveNotify
GitHub
add: [stix import] Import classification override parameter ยท MISP/misp-stix@3e5e7bd
The internal/external parser choice was made solely from labels or the
header title - content any producer can write - with no way to opt out.
The new classification parameter (also --classificatio...
header title - content any producer can write - with no way to opt out.
The new classification parameter (also --classificatio...
๐จ CVE-2025-23367
A flaw was found in the Wildfly Server Role Based Access Control (RBAC) provider. When authorization to control management operations is secured using the Role Based Access Control provider, a user without the required privileges can suspend or resume the server. A user with a Monitor or Auditor role is supposed to have only read access permissions and should not be able to suspend the server.
The vulnerability is caused by the Suspend and Resume handlers not performing authorization checks to validate whether the current user has the required permissions to proceed with the action.
๐@cveNotify
A flaw was found in the Wildfly Server Role Based Access Control (RBAC) provider. When authorization to control management operations is secured using the Role Based Access Control provider, a user without the required privileges can suspend or resume the server. A user with a Monitor or Auditor role is supposed to have only read access permissions and should not be able to suspend the server.
The vulnerability is caused by the Suspend and Resume handlers not performing authorization checks to validate whether the current user has the required permissions to proceed with the action.
๐@cveNotify
๐จ CVE-2026-47079
Inappropriate Encoding for Output Context vulnerability in joshnuss xml_builder (XmlBuilder module) allows Content Spoofing, Cross-site Scripting.
This vulnerability is associated with program files lib/xml_builder.ex and program routines XmlBuilder.generate/1, XmlBuilder.generate/2, XmlBuilder.escape_string/1, XmlBuilder.escape_entity/1.
XmlBuilder.generate/1 does not escape literal & characters in text or attribute values when they are followed by an entity-like token (lt;, gt;, amp;, quot;, apos;). As a result, attacker-supplied input such as <script> is emitted verbatim into the serialized XML rather than being escaped to &lt;script&gt;. When a downstream XML parser later reads the document, it decodes the entity sequences into the literal characters <script>, promoting inert-looking text into real markup. This allows an attacker to bypass upstream filters that block raw < and > characters, injecting markup into any downstream consumer that parses the produced XML and renders the text content in a markup-sensitive context (HTML, SVG, RSS/Atom feeds). Both element text and attribute values are affected.
This issue affects xml_builder: from 0.0.6 before 2.4.1.
๐@cveNotify
Inappropriate Encoding for Output Context vulnerability in joshnuss xml_builder (XmlBuilder module) allows Content Spoofing, Cross-site Scripting.
This vulnerability is associated with program files lib/xml_builder.ex and program routines XmlBuilder.generate/1, XmlBuilder.generate/2, XmlBuilder.escape_string/1, XmlBuilder.escape_entity/1.
XmlBuilder.generate/1 does not escape literal & characters in text or attribute values when they are followed by an entity-like token (lt;, gt;, amp;, quot;, apos;). As a result, attacker-supplied input such as <script> is emitted verbatim into the serialized XML rather than being escaped to &lt;script&gt;. When a downstream XML parser later reads the document, it decodes the entity sequences into the literal characters <script>, promoting inert-looking text into real markup. This allows an attacker to bypass upstream filters that block raw < and > characters, injecting markup into any downstream consumer that parses the produced XML and renders the text content in a markup-sensitive context (HTML, SVG, RSS/Atom feeds). Both element text and attribute values are affected.
This issue affects xml_builder: from 0.0.6 before 2.4.1.
๐@cveNotify
๐จ CVE-2026-47080
XML Injection vulnerability in joshnuss xml_builder (XmlBuilder module) allows Content Spoofing, XML Injection.
This vulnerability is associated with program files lib/xml_builder.ex and program routines XmlBuilder.generate/1, XmlBuilder.generate/2, XmlBuilder.escape/1.
The escape/1 clause for {:cdata, data} in lib/xml_builder.ex concatenates data verbatim between the CDATA opener <![CDATA[ and closer ]]> without rewriting or splitting on the embedded ]]> sequence. Because CDATA sections have no internal escape mechanism, the only safe way to embed arbitrary bytes is to split on ]]> and emit adjacent CDATA sections. An attacker who can supply input containing ]]> closes the CDATA section early; any bytes that follow are parsed as ordinary XML markup by downstream consumers, allowing injection of arbitrary elements, text, or entity references into the output document.
This issue affects xml_builder: from 0.0.7 before 2.4.1.
๐@cveNotify
XML Injection vulnerability in joshnuss xml_builder (XmlBuilder module) allows Content Spoofing, XML Injection.
This vulnerability is associated with program files lib/xml_builder.ex and program routines XmlBuilder.generate/1, XmlBuilder.generate/2, XmlBuilder.escape/1.
The escape/1 clause for {:cdata, data} in lib/xml_builder.ex concatenates data verbatim between the CDATA opener <![CDATA[ and closer ]]> without rewriting or splitting on the embedded ]]> sequence. Because CDATA sections have no internal escape mechanism, the only safe way to embed arbitrary bytes is to split on ]]> and emit adjacent CDATA sections. An attacker who can supply input containing ]]> closes the CDATA section early; any bytes that follow are parsed as ordinary XML markup by downstream consumers, allowing injection of arbitrary elements, text, or entity references into the output document.
This issue affects xml_builder: from 0.0.7 before 2.4.1.
๐@cveNotify
๐จ CVE-2026-47827
Command Injection in BOSH CLI tool on windows in Cloud Foundry allows a remote attacker to execute arbitrary shell commands via command injection vulnerabilities
๐@cveNotify
Command Injection in BOSH CLI tool on windows in Cloud Foundry allows a remote attacker to execute arbitrary shell commands via command injection vulnerabilities
๐@cveNotify
Cloud Foundry
CVE-2026-47827 - BOSH CLI Powershell Injection | Cloud Foundry
Severity HIGH CVSSv4: High 7.7 (CVSS:4.0/AV:A/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N) CVSSv3: High 7.5 (CVSS:3.0/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H) Vendor CloudFoundry Foundation Versions Affected *Severity is HIGH unless otherwise noted. BOSHโฆ
๐จ CVE-2026-48590
XML Injection vulnerability in joshnuss xml_builder (XmlBuilder module) allows Content Spoofing, XML Injection.
This vulnerability is associated with program files lib/xml_builder.ex and program routines XmlBuilder.generate/1, XmlBuilder.generate/2, XmlBuilder.element/1, XmlBuilder.element/2, XmlBuilder.element/3.
Element names, attribute names, and doctype identifiers are interpolated verbatim into the serialized XML output without validation or escaping of structural characters (<, >, ", ', &). An attacker who can influence a name argument (for example, an element name derived from a JSON object key or an HTTP form field name) can inject arbitrary XML markup including extra elements, comments, and event-handler attributes into the output document.
This issue affects xml_builder: from 0.0.1 before 2.4.1.
๐@cveNotify
XML Injection vulnerability in joshnuss xml_builder (XmlBuilder module) allows Content Spoofing, XML Injection.
This vulnerability is associated with program files lib/xml_builder.ex and program routines XmlBuilder.generate/1, XmlBuilder.generate/2, XmlBuilder.element/1, XmlBuilder.element/2, XmlBuilder.element/3.
Element names, attribute names, and doctype identifiers are interpolated verbatim into the serialized XML output without validation or escaping of structural characters (<, >, ", ', &). An attacker who can influence a name argument (for example, an element name derived from a JSON object key or an HTTP form field name) can inject arbitrary XML markup including extra elements, comments, and event-handler attributes into the output document.
This issue affects xml_builder: from 0.0.1 before 2.4.1.
๐@cveNotify
๐จ CVE-2026-59323
An application using Micrometer Tracing with W3C baggage propagation in the Brave bridge is vulnerable to denial of service (DoS) due to unbounded object allocation when extracting incoming baggage headers.
Specifically, an application is vulnerable when all the following are true:
* The application uses a vulnerable version of io.micrometer:micrometer-tracing-bridge-brave.
* W3C propagation is active (either configured manually or active by default, such as in Spring Boot 3.x+).
* Baggage propagation is enabled (which is the default in Spring Boot 3.x+) and a baggage manager (such as BraveBaggageManager) is configured to handle baggage fields.
* The application processes requests or messages from untrusted sources with baggage headers which it normally should not, see: https://www.w3.org/TR/trace-context/#security-considerations .
* Network components including the (HTTP) server that receives the request do not limit the header size or the limit is high enough to cause issues.
The last two points are very important: normally this should not affect applications because they should not receive untrusted and unlimited input for baggage.
* The application processes requests or messages from untrusted sources with baggage headers.
When extracting baggage from the W3C baggage header, incoming entries are parsed without enforcing limits on the number of entries or header size as mandated by the W3C Baggage specification. An attacker can send requests or messages with artificially inflated baggage headers containing many key-value pairs, causing unconditional BaggageField allocations per entry. This leads to garbage collection pressure, high CPU usage, and potential application crash via OutOfMemoryError.
๐@cveNotify
An application using Micrometer Tracing with W3C baggage propagation in the Brave bridge is vulnerable to denial of service (DoS) due to unbounded object allocation when extracting incoming baggage headers.
Specifically, an application is vulnerable when all the following are true:
* The application uses a vulnerable version of io.micrometer:micrometer-tracing-bridge-brave.
* W3C propagation is active (either configured manually or active by default, such as in Spring Boot 3.x+).
* Baggage propagation is enabled (which is the default in Spring Boot 3.x+) and a baggage manager (such as BraveBaggageManager) is configured to handle baggage fields.
* The application processes requests or messages from untrusted sources with baggage headers which it normally should not, see: https://www.w3.org/TR/trace-context/#security-considerations .
* Network components including the (HTTP) server that receives the request do not limit the header size or the limit is high enough to cause issues.
The last two points are very important: normally this should not affect applications because they should not receive untrusted and unlimited input for baggage.
* The application processes requests or messages from untrusted sources with baggage headers.
When extracting baggage from the W3C baggage header, incoming entries are parsed without enforcing limits on the number of entries or header size as mandated by the W3C Baggage specification. An attacker can send requests or messages with artificially inflated baggage headers containing many key-value pairs, causing unconditional BaggageField allocations per entry. This leads to garbage collection pressure, high CPU usage, and potential application crash via OutOfMemoryError.
๐@cveNotify
Micrometer Tracing Brave Bridge W3C Baggage propagation DoS vulnerability
Level up your Java code and explore what Spring can do for you.
๐จ CVE-2026-77681
A vulnerability was identified in CodeAstro Online Job Portal 1.0. Affected by this vulnerability is an unknown functionality of the file /users/update-profile.php. The manipulation of the argument Name leads to unrestricted upload. The attack can be initiated remotely. The exploit is publicly available and might be used.
๐@cveNotify
A vulnerability was identified in CodeAstro Online Job Portal 1.0. Affected by this vulnerability is an unknown functionality of the file /users/update-profile.php. The manipulation of the argument Name leads to unrestricted upload. The attack can be initiated remotely. The exploit is publicly available and might be used.
๐@cveNotify
๐จ CVE-2026-77751
A path traversal vulnerability existed in the handling of MISP object template names during STIX 2 import and MISP-to-STIX 2 export.
MISP object names are passed to PyMISP's object-template resolution mechanism, which constructs a filesystem path by joining the configured MISP object-template directory, the object name, and definition.json. An object name originating from untrusted STIX or MISP content was not sufficiently restricted before being used in this filesystem path.
An attacker able to supply a crafted object name containing path separators or traversal sequences such as ../ could therefore cause template resolution to escape the expected template directory and attempt to load a definition.json file from another location accessible to the process.
During STIX 2 import, an attacker-controlled x_misp_name from a custom STIX object could directly reach this template-resolution mechanism.
The issue could also become persistent. A malicious object name stored in a MISP event could later be processed again during STIX 2 export. Consequently, content originally introduced in one security context could trigger filesystem access later when the event is exported by a process operating with different or greater privileges.
If a suitable definition.json file exists outside the intended template directory, its contents may be interpreted as a MISP object template and fields from that file copied into the converted object. This can result in unintended disclosure of locally accessible data represented by the template file and modification of the resulting object's metadata or semantics.
The patches introduce strict validation of object-template names. Valid names are restricted to a single path component containing letters, digits, hyphens, or underscores. Names that do not meet these requirements are replaced with the generic unknown-template name before reaching PyMISP template resolution. The original rejected name is preserved in the object's comment and a warning is generated, preventing traversal while retaining the source information.
๐@cveNotify
A path traversal vulnerability existed in the handling of MISP object template names during STIX 2 import and MISP-to-STIX 2 export.
MISP object names are passed to PyMISP's object-template resolution mechanism, which constructs a filesystem path by joining the configured MISP object-template directory, the object name, and definition.json. An object name originating from untrusted STIX or MISP content was not sufficiently restricted before being used in this filesystem path.
An attacker able to supply a crafted object name containing path separators or traversal sequences such as ../ could therefore cause template resolution to escape the expected template directory and attempt to load a definition.json file from another location accessible to the process.
During STIX 2 import, an attacker-controlled x_misp_name from a custom STIX object could directly reach this template-resolution mechanism.
The issue could also become persistent. A malicious object name stored in a MISP event could later be processed again during STIX 2 export. Consequently, content originally introduced in one security context could trigger filesystem access later when the event is exported by a process operating with different or greater privileges.
If a suitable definition.json file exists outside the intended template directory, its contents may be interpreted as a MISP object template and fields from that file copied into the converted object. This can result in unintended disclosure of locally accessible data represented by the template file and modification of the resulting object's metadata or semantics.
The patches introduce strict validation of object-template names. Valid names are restricted to a single path component containing letters, digits, hyphens, or underscores. Names that do not meet these requirements are replaced with the generic unknown-template name before reaching PyMISP template resolution. The original rejected name is preserved in the object's comment and a warning is generated, preventing traversal while retaining the source information.
๐@cveNotify
GitHub
fix: [stix2 export] Replace object names that cannot name a template ยท MISP/misp-stix@a0f5407
A name stored in an event re-enters pymisp's template resolution when
that event is exported later, in a process that may hold different
privileges. Event and object dictionaries are now ch...
that event is exported later, in a process that may hold different
privileges. Event and object dictionaries are now ch...