**Related issue:** Resolves#47524
# Checklist for submitter
- [x] QA'd all new/changed functionality manually
## Context
[CVE-2026-34182](https://nvd.nist.gov/vuln/detail/CVE-2026-34182) (CVSS
9.1, Critical) is an OpenSSL CMS `AuthEnvelopedData` input-validation
flaw fixed in `openssl 3.5.7-r0`. The Alpine base image used by
`fleetdm/fleet` ships `3.5.6-r0`, which scanners (Aikido, Trivy) flag on
our published image.
`fleet serve` itself is statically compiled and does not link OpenSSL,
so the running process is unaffected — but the package is present in the
base image and shows up in customer-side SBOM scans.
## Approach
The issue's preferred path is a base-image SHA bump to `alpine:3.23.5`.
Docker Hub's latest `3.23.x` tag is still `3.23.4` (pushed 2026-04-15),
so that path isn't yet available. Applying the issue's fallback:
```dockerfile
RUN apk --no-cache upgrade openssl libcrypto3 libssl3
```
This pulls the patched `openssl 3.5.7-r0` from the Alpine 3.23 repos at
image build time without waiting on a new base tag. Once `alpine:3.23.5`
lands we can revert to a clean SHA-pinned `FROM` bump per the pattern in
#43671.
## Scope
Limited to `tools/fleet-docker/Dockerfile` per the issue's scope
guidance. Other Dockerfiles pinned to the same Alpine SHA (loadtest,
scep, mdmproxy) are out of scope here.
## Test plan
- [ ] CI image build passes.
- [ ] Trivy/scanner re-scan of the resulting `fleetdm/fleet` image
confirms CVE-2026-34182 is gone and `openssl` reports `3.5.7-r0`.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Chores**
* Updated OpenSSL and related packages in Docker image build
configuration to ensure the latest versions are included during image
creation.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
George Karr
bd28b7ccba