RHSA-2026:10153HighCVSS 9.1

Red Hat Security Advisory: RHTAS 1.3.4 - Red Hat Trusted Artifact Signer Release

Published
April 23, 2026
Last Modified
August 15, 2026

🔗 CVE IDs covered (3)

CVE-2026-40175 →CVE-2026-4926 →CVE-2026-33186 →

📋 Description

CVE-2026-4926 — path-to-regexp: path-to-regexp: Denial of Service via crafted regular expressions CVE-2026-33186 — google.golang.org/grpc/grpc-go: google.golang.org/grpc/authz: gRPC-Go: Authorization bypass due to improper HTTP/2 path validation CVE-2026-40175 — axios: Axios: Remote Code Execution via Prototype Pollution escalation

🎯 Affected products3

  • Red Hat Trusted Artifact Signer 1.3
  • registry.redhat.io/rhtas/rhtas-console-rhel9@sha256:52f189620a3aaf143b57009671b41ccd1b95700591ae863f00c50a7d54591901_amd64 as a component of Red Hat Trusted Artifact Signer 1.3
  • registry.redhat.io/rhtas/rhtas-console-ui-rhel9@sha256:8bf79d15df12c6af59d76463ebbf5c4d505752dfaea8a48ea9b9aa42fc8146d4_amd64 as a component of Red Hat Trusted Artifact Signer 1.3

✅ Remediation

Red Hat Trusted Artifact Signer simplifies cryptographic signing and verifying of software artifacts such as container images, binaries and source code changes. It is a self-managed on-premise deployment of the Sigstore project available at https://sigstore.dev Platform Engineers, Software Developers and Security Professionals may use RHTAS to ensure the integrity, transparency and assurance of their organization's software supply chain. For details on using the operator, refer to the product documentation at https://access.redhat.com/documentation/en-us/red_hat_trusted_artifact_signer/1.3 You can find the release notes for this version of Red Hat Trusted Artifact Signer at https://access.redhat.com/documentation/en-us/red_hat_trusted_artifact_signer/1.3/html-single/release_notes/index Workaround: To mitigate this vulnerability, limit the use of multiple sequential optional groups in route patterns within applications that use `path-to-regexp`. Additionally, avoid directly passing user-controlled input as route patterns to prevent the generation of maliciously crafted regular expressions. Workaround: To mitigate this issue, implement infrastructure-level normalization to ensure all incoming HTTP/2 `:path` headers are properly formatted with a leading slash before reaching the gRPC-Go server. This can be achieved by configuring a reverse proxy or API gateway to validate and normalize the `:path` header. Ensure that any such intermediary is properly configured and restarted to apply the changes, which may temporarily impact service availability.

🔗 References (8)