What happened?
The crowdsecurity/controller:v1.13.2 Docker image — the only available version of the CrowdSec ingress-nginx fork — contains multiple critical and high-severity CVEs in its base OS packages and compiled binaries.
Affected packages (detected by Aikido Security):
| Severity |
Package |
Issue |
| Critical |
nginx 1.25.5 |
No longer receiving security updates (~2 years EOL) |
| Critical |
openssl |
Memory corruption leading to crash or RCE |
| Critical |
libxml2 |
Out-of-bounds read, can expose sensitive info (fixed in ≥2.13.9-r0) |
| High |
Go stdlib |
Code injection vulnerability |
| High |
curl |
Out-of-bounds read, can expose sensitive info |
| Medium |
nginx |
Memory corruption leading to crash or RCE |
| Medium |
c-ares |
Use-after-free leading to DoS or RCE |
| Low |
busybox |
Minor vulnerability |
Since v1.13.2 is the only published tag and upstream ingress-nginx removed Lua support in v1.12, all CrowdSec Kubernetes users relying on the Lua bouncer are locked into this vulnerable image with no upgrade path.
What did you expect to happen?
We expect the crowdsecurity/controller image to receive periodic rebuilds to pick up security patches in OS-level dependencies (Alpine base image) and to be based on a nginx version that still receives security updates.
Short-term: Rebuild v1.13.2 with an updated Alpine base image (fixes openssl, libxml2, curl, c-ares, busybox).
Medium-term: Release a new controller version based on a supported nginx version.
How can we reproduce it (as minimally and precisely as possible)?
Pull the image and scan it with any container vulnerability scanner:
docker pull crowdsecurity/controller:v1.13.2
docker scout cves crowdsecurity/controller:v1.13.2
or with Trivy:
trivy image crowdsecurity/controller:v1.13.2
Image digest: sha256:4575be24781cad35f8e58437db6a3f492df2a3167fed2b6759a6ff0dc3488d56
Anything else we need to know?
- OS-level packages (openssl, libxml2, curl, c-ares, busybox) are patchable via
apk upgrade in a rebuilt image
- nginx and Go stdlib vulnerabilities require recompilation of the controller binary
- We are currently evaluating building a custom patched image as a workaround, but this shifts maintenance burden to end users
- Helm chart version in use: crowdsec/crowdsec v0.22.0
- Environment: Kubernetes with three ingress controllers, all using crowdsecurity/controller:v1.13.2 with the Lua bouncer init container pattern
Crowdsec version
Details
Helm chart: crowdsec/crowdsec v0.22.0
Controller image: crowdsecurity/controller:v1.13.2
Bouncer: crowdsecurity/lua-bouncer-plugin:v1.1.2
OS version
Details
Container base image: Alpine Linux (exact version unknown — bundled in crowdsecurity/controller:v1.13.2)
Host: N/A — this is about the container image, not the host OS
Enabled collections and parsers
Details
Collections:
- crowdsecurity/nginx
- crowdsecurity/http-cve
- crowdsecurity/base-http-scenarios
- crowdsecurity/appsec-virtual-patching
- crowdsecurity/appsec-generic-rules
- crowdsecurity/appsec-crs
Parsers:
- custom/nginx-magnolia-logs (custom parser for non-standard Magnolia ingress log format)
- Standard parsers from the nginx collection
Acquisition config
Details
# On Linux:
$ cat /etc/crowdsec/acquis.yaml /etc/crowdsec/acquis.d/*
# paste output here
# On Windows:
C:\> Get-Content C:\ProgramData\CrowdSec\config\acquis.yaml
# paste output here
Config show
Details
$ cscli config show
# paste output here
Prometheus metrics
Details
$ cscli metrics
# paste output here
Related custom configs versions (if applicable) : notification plugins, custom scenarios, parsers etc.
Details
What happened?
The
crowdsecurity/controller:v1.13.2Docker image — the only available version of the CrowdSec ingress-nginx fork — contains multiple critical and high-severity CVEs in its base OS packages and compiled binaries.Affected packages (detected by Aikido Security):
Since v1.13.2 is the only published tag and upstream ingress-nginx removed Lua support in v1.12, all CrowdSec Kubernetes users relying on the Lua bouncer are locked into this vulnerable image with no upgrade path.
What did you expect to happen?
We expect the crowdsecurity/controller image to receive periodic rebuilds to pick up security patches in OS-level dependencies (Alpine base image) and to be based on a nginx version that still receives security updates.
Short-term: Rebuild v1.13.2 with an updated Alpine base image (fixes openssl, libxml2, curl, c-ares, busybox).
Medium-term: Release a new controller version based on a supported nginx version.
How can we reproduce it (as minimally and precisely as possible)?
Pull the image and scan it with any container vulnerability scanner:
docker pull crowdsecurity/controller:v1.13.2
docker scout cves crowdsecurity/controller:v1.13.2
or with Trivy:
trivy image crowdsecurity/controller:v1.13.2
Image digest: sha256:4575be24781cad35f8e58437db6a3f492df2a3167fed2b6759a6ff0dc3488d56
Anything else we need to know?
apk upgradein a rebuilt imageCrowdsec version
Details
OS version
Details
Enabled collections and parsers
Details
Acquisition config
Details
Config show
Details
Prometheus metrics
Details
Related custom configs versions (if applicable) : notification plugins, custom scenarios, parsers etc.
Details