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.

The issue is about rebuilding the Docker image for the 3.1.4 release to update the vulnerable bind packages. Look at the repository's Dockerfile and CI/CD configuration (likely in .github/workflows or similar) to understand how images are built and tagged. The task involves triggering a rebuild of the same source commit to pick up the updated Alpine packages. Check if there's a release workflow that can be manually triggered or if a new patch release needs to be cut. Verify the fix by building the image locally and scanning it with Trivy to confirm no HIGH CVEs remain.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.