Affected: axios, Red Hat Ansible Automation Platform 2.5 for RHEL 8, Red Hat Ansible Automation Platform 2.5 for RHEL 9, Red Hat Streams for Apache Kafka 3.2.0, Red Hat Cluster Observability Operator 1.5.0, Red Hat multicluster engine for Kubernetes 2.6, Red Hat multicluster engine for Kubernetes 2.8, Red Hat Network Observability (NETOBSERV) 1.11.0, Red Hat Advanced Cluster Management for Kubernetes 2.14, Red Hat Advanced Cluster Security 4.9 and 53 more

Axios is a promise based HTTP client for the browser and Node.js. Prior to 1.15.0 and 0.31.0, Axios does not correctly handle hostname normalization when checking NO_PROXY rules. Requests to loopback addresses like localhost. (with a trailing dot) or [::1] (IPv6 literal) skip NO_PROXY matching and go through the configured proxy. This goes against what developers expect and lets attackers force requests through a proxy, even if NO_PROXY is set up to protect loopback or internal services. This issue leads to the possibility of proxy bypass and SSRF vulnerabilities allowing attackers to reach sensitive loopback or internal services despite the configured protections. This vulnerability is fixed in 1.15.0 and 0.31.0.

Affected: npm: node-forge

## Summary

`pki.verifyCertificateChain()` does not enforce RFC 5280 basicConstraints requirements when an intermediate certificate lacks both the `basicConstraints` and `keyUsage` extensions. This allows any leaf certificate (without these extensions) to act as a CA and sign other certificates, which node-forge will accept as valid.

## Technical Details

In `lib/x509.js`, the `verifyCertificateChain()` function (around lines 3147-3199) has two conditional checks for CA authorization:

1. The `keyUsage` check (which includes a sub-check requiring `basicConstraints` to be present) is gated on `keyUsageExt !== null` 2. The `basicConstraints.cA` check is gated on `bcExt !== null`

When a certificate has **neither** extension, both checks are skipped entirely. The certificate passes all CA validation and is accepted as a valid intermediate CA.

**RFC 5280 Section 6.1.4 step (k) requires:** > "If certificate i is a version 3 certificate, verify that the basicConstraints extension is present and that cA is set to TRUE."

The absence of `basicConstraints` should result in rejection, not acceptance.

## Proof of Concept

```javascript const forge = require('node-forge'); const pki = forge.pki;

function generateKeyPair() { return pki.rsa.generateKeyPair({ bits: 2048, e: 0x10001 }); }

console.log('=== node-forge basicConstraints Bypass PoC ===\n');

// 1. Create a legitimate Root CA (self-signed, with basicConstraints cA=true) const rootKeys = generateKeyPair(); const rootCert =…