grpcurl
grpcurl copied to clipboard
fix CVEs
usr/bin/grpcurl (gobinary)
==========================
Total: 1 (LOW: 0, MEDIUM: 1, HIGH: 0, CRITICAL: 0)
┌─────────┬────────────────┬──────────┬────────┬───────────────────┬────────────────┬──────────────────────────────────────────────────────────┐
│ Library │ Vulnerability │ Severity │ Status │ Installed Version │ Fixed Version │ Title │
├─────────┼────────────────┼──────────┼────────┼───────────────────┼────────────────┼──────────────────────────────────────────────────────────┤
│ stdlib │ CVE-2025-22871 │ MEDIUM │ fixed │ 1.24.1 │ 1.23.8, 1.24.2 │ net/http: Request smuggling due to acceptance of invalid │
│ │ │ │ │ │ │ chunked data in net/http... │
│ │ │ │ │ │ │ https://avd.aquasec.com/nvd/cve-2025-22871 │
└─────────┴────────────────┴──────────┴────────┴───────────────────┴────────────────┴──────────────────────────────────────────────────────────┘
Hi @jplimack can you describe the attack vector for grpcurl?
https://avd.aquasec.com/nvd/cve-2025-22871
The attack vector exploits how HTTP chunked transfer encoding is parsed by different servers: the Go net/http package erroneously accepts a bare LF as the end-of-line marker in chunk-size lines instead of the proper CRLF. An attacker can craft a malicious request with LF characters in place of the expected CRLF, causing a discrepancy between servers where one interprets the LF as a line terminator while another includes it as part of the chunk extension. This mismatch allows the attacker to "smuggle" extra headers or even entire requests into the data stream, leading to potential bypassing of security controls and unauthorized request manipulation.
I include grpcurl within some container images and these images must pass vuln scanning to be published to my production registry, and was able to fix the issue my simply upgrading the packages/go.