https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 10 Oct 2026 16:45:24 +0000 https://cve.radiocsirt.org/vuln/cve-2021-41130 <p><strong>Affected:</strong> cloudendpoints esp</p> <p>Extensible Service Proxy, a.k.a. ESP is a proxy which enables API management capabilities for JSON/REST or gRPC API services. ESPv1 can be configured to authenticate a JWT token. Its verified JWT claim is passed to the application by HTTP header &#34;X-Endpoint-API-UserInfo&#34;, the application can use it to do authorization. But if there are two &#34;X-Endpoint-API-UserInfo&#34; headers from the client, ESPv1 only replaces the first one, the 2nd one will be passed to the application. An attacker can send two &#34;X-Endpoint-API-UserInfo&#34; headers, the second one with a fake JWT claim. Application may use the fake JWT claim to do the authorization. This impacts following ESPv1 usages: 1) Users have configured ESPv1 to do JWT authentication with Google ID Token as described in the referenced google endpoint document. 2) Users backend application is using the info in the &#34;X-Endpoint-API-UserInfo&#34; header to do the authorization. It has been fixed by v1.58.0. You need to patch it in the following ways: * If your docker image is using tag &#34;:1&#34;, needs to re-start the container to pick up the new version. The tag &#34;:1&#34; will automatically point to the latest version. * If your docker image tag pings to a specific minor version, e.g. &#34;:1.57&#34;. You need to update it to &#34;:1.58&#34; and re-start the container. There are no workaround for this issue.</p> <p><strong>Affected:</strong> cloudendpoints esp</p> <p>Extensible Service Proxy, a.k.a. ESP is a proxy which enables API management capabilities for JSON/REST or gRPC API services. ESPv1 can be configured to authenticate a JWT token. Its verified JWT claim is passed to the application by HTTP header &#34;X-Endpoint-API-UserInfo&#34;, the application can use it to do authorization. But if there are two &#34;X-Endpoint-API-UserInfo&#34; headers from the client, ESPv1 only replaces the first one, the 2nd one will be passed to the application. An attacker can send two &#34;X-Endpoint-API-UserInfo&#34; headers, the second one with a fake JWT claim. Application may use the fake JWT claim to do the authorization. This impacts following ESPv1 usages: 1) Users have configured ESPv1 to do JWT authentication with Google ID Token as described in the referenced google endpoint document. 2) Users backend application is using the info in the &#34;X-Endpoint-API-UserInfo&#34; header to do the authorization. It has been fixed by v1.58.0. You need to patch it in the following ways: * If your docker image is using tag &#34;:1&#34;, needs to re-start the container to pick up the new version. The tag &#34;:1&#34; will automatically point to the latest version. * If your docker image tag pings to a specific minor version, e.g. &#34;:1.57&#34;. You need to update it to &#34;:1.58&#34; and re-start the container. There are no workaround for this issue.</p> https://cve.radiocsirt.org/vuln/cve-2021-41130