Release image 3.1.4 ships vulnerable bind-tools/bind-libs 9.20.23-r0 (9 CVEs) — please rebuild/re-tag the release

### Summary

The published release image `neilpang/acme.sh:3.1.4` (`sha256:08bad323dd6537ea2caba64260ef6e70e96057c4d9214afb9c07861db26653d9`, built 2026-07-17, revision `3661fd86`) contains **`bind-tools` and `bind-libs` 9.20.23-r0**, which Alpine has since fixed in **9.20.26-r0**. That accounts for 9 CVEs (7 HIGH, 2 MEDIUM) — and they are the *only* vulnerable packages in the image, so a plain rebuild clears the scan completely.

`neilpang/acme.sh:latest` (pushed 2026-08-13) already picked up `9.20.26-r0` on rebuild. The problem is only that the immutable release tag was never rebuilt, so everyone who pins a version (as recommended for reproducible deployments) is stuck on the vulnerable base.

### Affected packages

| Package | In image `3.1.4` | Fixed in Alpine v3.23 |
|---|---|---|
| `bind-tools` | 9.20.23-r0 | 9.20.26-r0 |
| `bind-libs` | 9.20.23-r0 | 9.20.26-r0 |

Base OS: Alpine 3.23.5. The current `v3.23/main` APKINDEX offers `bind*` 9.20.26-r0.

### CVEs (fixed in bind 9.20.26-r0)

| CVE | Severity | CVSS v3 | Description |
|---|---|---|---|
| CVE-2026-13321 | HIGH | 8.6 | DNSSEC validation bypass via out-of-zone NSEC next field |
| CVE-2026-11331 | HIGH | 7.5 | Potential wildcard CNAME RPZ policy bypass |
| CVE-2026-11605 | HIGH | 7.5 | Unnecessary validation of DNSSEC signed records |
| CVE-2026-11622 | HIGH | 7.5 | Potential memory usage beyond configured limits |
| CVE-2026-11721 | HIGH | 7.5 | Cache poisoning via label count discrepancy, RRSIG, wildcards |
| CVE-2026-12617 | HIGH | 7.5 | Record-ordering based unexpected exit with CNAME or DNAME |
| CVE-2026-13204 | HIGH | 7.5 | Unexpected exit with NSEC and NSEC3 both present |
| CVE-2026-10723 | MEDIUM | 6.8 | Incorrect acceptance of NSEC3 records |
| CVE-2026-10822 | MEDIUM | 6.5 | KEY record using PRIVATEDNS algorithm may lead to exit |

Sources: [Alpine secdb v3.23](https://secdb.alpinelinux.org/v3.23/main.json), Trivy DB.

### Why this matters for acme.sh users

To be precise about exploitability: most of these CVEs are in BIND's resolver/`named` code paths, and this image does not run `named` — it ships the client tools. The direct runtime exposure is therefore limited to the bind-tools binaries acme.sh actually invokes (`nsupdate`, used by `dnsapi/dns_nsupdate.sh` for RFC2136 DNS-01 updates) and the shared `bind-libs` they link against, which include the affected DNSSEC record-parsing code.

The concrete, unarguable impact is on the consuming side: any image scanner (Trivy, Grype, Harbor, registry-side scanning) reports **7 HIGH and 2 MEDIUM findings** against the pinned `3.1.4` image, all of them with a fixed version available. In environments with a "no HIGH CVEs in production images" gate that blocks deployment outright, and the only remedies available to users are unpinning to `latest` (losing reproducibility) or maintaining a local rebuild — both worse than an upstream rebuild.

### Reproduction

```console
$ docker run --rm --entrypoint sh \
neilpang/acme.sh:3.1.4@sha256:08bad323dd6537ea2caba64260ef6e70e96057c4d9214afb9c07861db26653d9 \
-c 'cat /etc/alpine-release; apk info -v | grep ^bind'
3.23.5
bind-libs-9.20.23-r0
bind-tools-9.20.23-r0

$ trivy image --scanners vuln neilpang/acme.sh:3.1.4@sha256:08bad323...
Total: 18 (MEDIUM: 4, HIGH: 14) # 9 CVEs x 2 packages, all bind-*
```

And for comparison, `latest` is already clean:

```console
$ docker run --rm --entrypoint sh neilpang/acme.sh:latest \
-c 'apk info -v | grep ^bind'
bind-libs-9.20.26-r0
bind-tools-9.20.26-r0
```

### Request

Please do one of the following:

1. **Rebuild and re-push `3.1.4`** from the unchanged `3661fd86` source tree so it picks up the patched Alpine packages, or
2. **Cut a `3.1.5` patch release** (no code change needed — a rebuild is enough), or
3. **Publish periodic rebuilds of the newest release tag** (e.g. a scheduled CI job) so version-pinning users get base-image security updates without waiting for a functional release.

Option 3 would prevent this from recurring: since the image only ever contains acme.sh plus a handful of Alpine packages, an unrebuilt release tag inevitably accumulates OS CVEs over its lifetime. If the release tags are meant to be strictly immutable, then a date-suffixed rebuild tag (`3.1.4-20260824`) would also work for us.

Happy to test any rebuilt image and report scan results back. Thank you for your work.