I have not touched AWX much lately. A conversation at a conference rekindled my curiosity: someone told me they still run AWX in production, then mentioned almost in passing that the project had not shipped a version in a good while. The remark nagged at me.
Back at my desk, I wanted to see what that meant concretely. I pulled the latest official image and ran a vulnerability scanner over it: 45 CVEs, 3 of them critical. All of them sitting in a version that has not moved in two years. This is not an AWX bug, it is the consequence of a decision that went almost unnoticed: since the summer of 2024, the project no longer publishes releases.
If you run AWX in production or in a homelab, you may be affected without knowing it. Here are the numbers and the option I settled on.
What happened: no release since July 2024
The last published AWX version is 24.6.1, dated 2 July 2024. Nothing since: no tag, no official image in the registry. This is not abandonment. The team started a deep rework toward a decoupled architecture, extracting the interface, the inventory and the credential types into separate services, and switched from semantic versioning to CalVer. During that work, releases are frozen.
The problem is the silence around that freeze. A GitHub issue asking for the
next release date stayed open for months without a firm answer. A community team
member eventually acknowledged publicly that communication had not been good
enough. In short: development continues at pace on the devel branch, but no
deliverable reaches users.
The real problem: a frozen image is a CVE stockpile
A container image does not age well. Its base system, its Python packages and its libraries are frozen on build day. Every vulnerability discovered later in those components accumulates, never fixed. Two years is a very long time on the CVE timescale.
The measurement is reproducible in one line. I ran quay.io/ansible/awx:24.6.1
through Trivy, keeping only critical and high severities:
trivy image --severity CRITICAL,HIGH quay.io/ansible/awx:24.6.1The verdict is unambiguous: 3 critical and 42 high vulnerabilities, that is 45 unique CVEs, almost all in Python dependencies frozen in mid-2024. Running that image today means deliberately exposing a known, unpatched attack surface.
Two tempting ideas that do not hold
Faced with this, two reflexes come naturally. Neither survives contact.
Staying on 24.6.1 and accepting it. That is the default choice of anyone who does not know the project is frozen. We just saw the price: 45 CVEs including 3 critical, and it gets worse every month.
Building the image yourself from devel. The idea is appealing: recent code
has fresher dependencies. I wanted to verify rather than believe. I cloned the
repository, pinned a specific commit for reproducibility, and ran the official
production image build:
make awx-kube-buildThe image builds correctly and the code loads without error. On the security
side it drops to 0 critical and 27 high CVEs: better than the frozen image,
inevitably. But two problems remain. First, devel is mid-rework, and its
own maintainers warn that parts of the application may break without notice.
Second, that image is stale the next day: devel moves daily, so you would
rebuild continuously and retest every time. That is a continuous integration job
to own, not a turnkey solution.
The option I settled on: Ascender
While looking at how others cope, I came across Ascender, an AWX fork maintained by Ctrl IQ, the people behind Rocky Linux. Its bet is exactly what AWX lacks: keep publishing stable, patched versions.
And it is not a dormant project. Releases ship on a monthly cadence (25.4.0 dates from June 2026), and each release note explicitly lists CVE fixes in dependencies such as Django, cryptography and aiohttp. I ran the latest image through the same scanner, under the same conditions:
trivy image --severity CRITICAL,HIGH ghcr.io/ctrliq/ascender:25.4.0Result: 0 critical and 22 high CVEs. Ascender not only removes the three
critical vulnerabilities of the frozen image, it also does better than my own
image built from devel (22 against 27). The lesson is counter-intuitive but
clear: a fork that actively updates its dependencies beats building raw code
yourself.
Here are the three paths side by side, on comparably sized images:
| Image | Critical | High CVEs (unique) | Maintained |
|---|---|---|---|
| AWX 24.6.1 (frozen official) | 3 | 45 | no |
Self-build from devel | 0 | 27 | your responsibility |
| Ascender 25.4.0 | 0 | 22 | yes, monthly |
Ascender also ships its own installer, either a single k3s VM or a deployment on the main managed Kubernetes offerings, plus a migration path from AWX. For anyone who wants a recent, secure and stable AWX without turning their automation platform into a full-time project, it is the most direct answer.
When building it yourself still makes sense
I am not discarding the self-build. It stays relevant in specific cases: an air-gapped environment where you must control every layer of the image, an internal integration chain that rebuilds and scans automatically on every change, an end-to-end supply chain audit requirement. In those situations, producing and scanning your own image is a genuine security move. But you then have to pin a commit, test before promoting, and rebuild regularly. That is a commitment, not a shortcut.
If you have the budget and need contractual support, AAP (Ansible Automation Platform) remains Red Hat's commercial path: the supported version, built for enterprises, where AWX has always been a moving upstream project.
Picking an image is not enough: mitigate continuously
Choosing the right base is only a start. Even the Ascender image, the healthiest of the three, still carries 22 high vulnerabilities. No container image is 100 % clean, and more importantly none stays clean: new CVEs land every week against dependencies.
Image security is not a state, it is a process. A Trivy scan gives a snapshot at time T; for tracking over time, a platform such as Dependency-Track is better suited. You push the image SBOM to it, in CycloneDX format produced by Trivy or Syft, and it continuously re-evaluates those components: as soon as a new CVE hits a brick already deployed, it alerts you, with no scan to rerun. Add two simple reflexes: follow the updates of whichever solution you picked, and redeploy regularly. On each new version I allow myself a quarantine period, long enough to check it introduces neither regression nor new problem, unless exploitability is high: in that case, patch immediately. The point is never to let an image freeze, which was the original trap.
Scanning also does not replace classic mitigations: do not expose the AWX interface directly on the internet, apply least privilege, isolate the network, patch the host. A fresher image reduces the attack surface, it does not remove it.
Key takeaways
- AWX has published no release since 2 July 2024, during an architecture rework and a move to CalVer.
- The official 24.6.1 image accumulates 45 CVEs, 3 of them critical: leaving it in production is a risk that grows every month.
- Building from
develreduces CVEs (0 critical, 27 high) but exposes you to the instability of the rework and to permanent maintenance. - Ascender, the fork maintained by Ctrl IQ, offers 0 critical and 22 CVEs, monthly patched releases and an installer: the option I recommend by default.
- Self-building is only justified for air-gapped setups, internal CI or supply chain audits; AAP covers the commercial support need.
- Counter-intuitive but measured: a fork that updates its dependencies beats self-building raw code.
- Choosing a healthy image is not enough: you must mitigate continuously, because no image stays clean.