文章

发布于

Recommending 3+1 for all ClouDNS Premium users

What happened

https://www.dnsperf.com/dns-provider/cloudns

On 2026-06-26, every ClouDNS Premium anycast nameserver for my zones and my friend’s zone experienced a major outage – periodic timeouts on UDP/53 within a ~20-minute window:

~12:39 UTC (21:39 JST) — first symptom: my friend’s domain failed to resolve due to a DNS timeout (;; communications error to <ip>#53: timed out), as his NS vanities point to pns41–44.
~12:44 UTC (21:44 JST) — reproduced directly against my own zones (pns1–4).
~12:59 UTC (21:59 JST) — last observation; recovered on its own shortly after.

IPs in Premium Anycast timed out, plus the standard ns3. The standard ns1/ns2/ns4 answered normally throughout. (However, note that ns1 is a problematic server, as I mentioned in my past article, and I do not recommend using it as the +1.)

Four groups of anycast nameservers, yet somehow they provide no redundancy between one another. BGP misconfiguration? A bad rollout? There’s no way to tell, as there’s zero public statement from ClouDNS themselves – support ticket only confirmed a “temporary technical situation” in their reply, with zero detail about what went wrong, and they don’t have a status page as far as I know.

The fix: 3+1 (or 4+1 if you prefer)

Replace one of the four anycast nodes with one of ClouDNS’s standard (unicast) nameservers. Three premium anycast for speed, one standard unicast on a separate network as insurance.

Test a few standard nameservers directly and pick one that’s both well-routed from your audience and on a different network from the anycast fleet:

dig @<ip> yourdomain SOA +norecurse    # authoritative? same serial?

With this setup, when the anycast set goes quiet again, your domain stays up.

发布于

CVE-2026-42945：潛伏 18 年的 NGINX 高危漏洞

今日披露的 NGINX Rift 漏洞，属于 ngx_http_rewrite_module 中的一個堆緩衝區溢出，自 2008 年起存在於程式碼庫中。攻擊者無需任何認證，只需發送一個構造好的 HTTP 請求，即可令 NGINX worker 程序崩潰（單一請求即可穩定觸發 DoS）；若目標系統關閉了 ASLR，則可進一步實現遠端程式碼執行。

觸發條件須同時滿足以下三點：

  1. rewrite 替換字串中使用了無名捕獲組（$1、$2 等）
  2. 替換字串中包含 ?（即構造了查詢字串）
  3. rewrite 指令後方緊跟另一條 rewrite、if 或 set 指令

rewrite 規則在國內運用極為普遍，而 Discuz! X 官方推薦的偽靜態規則全部命中上述三個條件，大量 LNMP 面板、虛擬主機和 VPS 使用者沿用至今：

Note: AMH 面板已經發佈 NGINX 1.30.1。（https://amh.sh/bbs/post-11462-1-1.htm）
rewrite ^([^\.]*)/topic-(.+)\.html$ $1/portal.php?mod=topic&topic=$2 last;
rewrite ^([^\.]*)/article-([0-9]+)-([0-9]+)\.html$ $1/portal.php?mod=view&aid=$2&page=$3 last;
rewrite ^([^\.]*)/forum-(\w+)-([0-9]+)\.html$ $1/forum.php?mod=forumdisplay&fid=$2&page=$3 last;
rewrite ^([^\.]*)/thread-([0-9]+)-([0-9]+)-([0-9]+)\.html$ $1/forum.php?mod=viewthread&tid=$2&extra=page%3D$4&page=$3 last;
rewrite ^([^\.]*)/group-([0-9]+)-([0-9]+)\.html$ $1/forum.php?mod=group&fid=$2&page=$3 last;
rewrite ^([^\.]*)/space-(username|uid)-(.+)\.html$ $1/home.php?mod=space&$2=$3 last;
rewrite ^([^\.]*)/blog-([0-9]+)-([0-9]+)\.html$ $1/home.php?mod=space&uid=$2&do=blog&id=$3 last;
rewrite ^([^\.]*)/archiver/(fid|tid)-([0-9]+)\.html$ $1/archiver/index.php?action=$2&value=$3 last;
rewrite ^([^\.]*)/([a-z]+[a-z0-9_]*)-([a-z0-9_\-]+)\.html$ $1/plugin.php?id=$2:$3 last;


9 條規則全部滿足觸發條件：

無名捕獲組（$1、$2 等）替換字串含 ?後跟 rewrite/if/set
✅✅✅

溢出量的大小取決於捕獲變數的內容，漏洞路徑是 ngx_http_script_copy_capture_code 透過 ngx_escape_uri（NGX_ESCAPE_ARGS 模式）對捕獲變數重新跳脫，+、%、& 各從 1 byte 膨脹為 3 bytes。捕獲組的正則越寬鬆，攻擊者能製造的溢出量就越大：

  • 最危險：topic-(.+) 與 space-…-(.+) 的捕獲組是 .+，攻擊者可任意填入 +、%、&，溢出量完全可控
  • 相對難利用：thread-([0-9]+) 的捕獲組限定為純數字，無法觸發字元膨脹

臨時修復：將無名捕獲組改為具名捕獲組

無需修改任何業務邏輯，只需在每個捕獲組的括號內加上 ?<名稱>，並在替換字串中改用 $名稱 引用，即可繞過存在漏洞的程式碼路徑。以第一條規則為例：

修改前
rewrite ^([^.]*)/topic-(.+).html$ $1/portal.php?mod=topic&topic=$2 last;

修改後
rewrite ^(?<base>[^.]*)/topic-(?<slug>.+).html$ $base/portal.php?mod=topic&topic=$slug last;

Discuz! X 完整修復版本：

rewrite ^(?<base>[^\.]*)/topic-(?<slug>.+)\.html$                                        $base/portal.php?mod=topic&topic=$slug last;
rewrite ^(?<base>[^\.]*)/article-(?<aid>[0-9]+)-(?<page>[0-9]+)\.html$                  $base/portal.php?mod=view&aid=$aid&page=$page last;
rewrite ^(?<base>[^\.]*)/forum-(?<fid>\w+)-(?<page>[0-9]+)\.html$                       $base/forum.php?mod=forumdisplay&fid=$fid&page=$page last;
rewrite ^(?<base>[^\.]*)/thread-(?<tid>[0-9]+)-(?<page>[0-9]+)-(?<extra>[0-9]+)\.html$  $base/forum.php?mod=viewthread&tid=$tid&extra=page%3D$extra&page=$page last;
rewrite ^(?<base>[^\.]*)/group-(?<fid>[0-9]+)-(?<page>[0-9]+)\.html$                    $base/forum.php?mod=group&fid=$fid&page=$page last;
rewrite ^(?<base>[^\.]*)/space-(?<type>username|uid)-(?<val>.+)\.html$                  $base/home.php?mod=space&$type=$val last;
rewrite ^(?<base>[^\.]*)/blog-(?<uid>[0-9]+)-(?<id>[0-9]+)\.html$                       $base/home.php?mod=space&uid=$uid&do=blog&id=$id last;
rewrite ^(?<base>[^\.]*)/archiver/(?<action>fid|tid)-(?<value>[0-9]+)\.html$            $base/archiver/index.php?action=$action&value=$value last;
rewrite ^(?<base>[^\.]*)/(?<plug>[a-z]+[a-z0-9_]*)-(?<parg>[a-z0-9_\-]+)\.html$        $base/plugin.php?id=$plug:$parg last;

修改後驗證並重載：

nginx -t && nginx -s reload

受影響版本

NGINX Open Source 0.6.27 – 1.30.0（詳見 F5 官方公告）
上述設定改法僅作為無法立即升級時的臨時緩解措施。PoC 已公開發布於 DepthFirstDisclosures/Nginx-Rift。

发布于

Critical Linux Kernel 0-Day: Instant Root Shell on All Distros Since 2017

A newly disclosed Linux kernel vulnerability, CVE-2026-31431 (“CopyFail”), gives any unprivileged local user an instant, unconditional root shell on virtually every Linux distribution shipped since 2017 – including Ubuntu, RHEL, Amazon Linux, and SUSE.

Unlike previous high-profile kernel exploits, the entire proof-of-concept is a 732-byte Python script using only the standard library. It exploits a logic flaw in authencesn to perform a controlled page-cache write, patching any setuid binary in memory without touching disk – bypassing file integrity tools and crossing container boundaries.

Exploitation requires only an unprivileged local shell; no race condition, no kernel offsets, no compiled payload.

Immediate action required. As a stopgap, disable algif_aead via modprobe (details):

echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf && rmmod algif_aead

Then prioritize kernel patching to 6.18.22+, 6.19.12+, or 7.0+.

Note that some distributions – including Debian – had not released a patched kernel as of 2026-04-30 03:00 UTC; monitor your vendor’s security advisories closely (Debian tracker).
2026-05-02 Update: linux-image-6.12.85+deb13-amd64 has been released.

CI runners, shared hosts, and Kubernetes nodes are highest priority.

发布于

Recommending IPSet over firewallcmd-multiport

I run a small setup with fail2ban protecting nginx and SSH. The setup worked fine – fail2ban watches logs, detects attackers, and bans them via firewalld. Nothing exotic.

After accumulating hundreds of bans across my f2b jails, fail2ban-client reload became noticeably slow. The default firewallcmd-multiport action adds one firewall rule per banned IP, so every reload rebuilds hundreds of individual rules.

Enter IPSet, per Claude, instead of one rule per IP, it stores all banned IPs in a kernel-level hash table behind a single firewall rule. Lookup is O(1) regardless of how many IPs are in the set. Fail2ban already ships with firewallcmd-ipset.conf, so the switch is just a config change:

# /etc/jail.d/defaults-debian.conf
[DEFAULT]
banaction = firewallcmd-ipset
banaction_allports = firewallcmd-ipset[actiontype=<allports>]

After systemctl restart fail2ban, fail2ban-client reload went instant — even with 300+ IPs banned across three jails.

To verify fail2ban and ipset stay in sync on every login:

echo "=== Fail2Ban IPSet Status ==="
for jail in $(fail2ban-client status | sed -n 's/,//g;s/.*Jail list://p'); do
    f2b_count=$(fail2ban-client status "$jail" | awk '/Currently banned/{print $NF}')
    ipset_count=$(ipset list "f2b-$jail" 2>/dev/null | awk '/Number of entries/{print $NF}')
    printf "%-30s banned: %-6s ←→  ipset entries: %s\n" "$jail" "$f2b_count" "${ipset_count:-0}"
done
发布于

Weird Default Zone Settings by ClouDNS

This site was recently migrated to ClouDNS from DNSMadeEasy. Everything went smoothly, especially with Claude’s help automating the migration script via zonefile and API.

However, during post-migration testing, I found a weird behavior with ClouDNS’ Premium plan nameservers: they return 127.0.0.1 as an authoritative answer for domains that are not hosted on their system.

For example, querying pns1.cloudns.net for google.com – a domain that obviously has nothing to do with ClouDNS:

~$ dig google.com @pns1.cloudns.net. +noedns +norec

; <<>> DiG 9.18.28-1~deb12u2-Debian <<>> google.com @pns1.cloudns.net. +noedns +norec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7556
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;google.com.                    IN      A

;; ANSWER SECTION:
google.com.             120     IN      A       127.0.0.1

;; AUTHORITY SECTION:
.                       120     IN      NS      localhost.

;; Query time: 12 msec
;; SERVER: 185.136.96.111#53(pns1.cloudns.net.) (UDP)
;; WHEN: Fri Apr 10 21:32:38 JST 2026
;; MSG SIZE  rcvd: 66

Note the aa (authoritative answer) flag in the response. This server is claiming to be authoritative for google.com, returning 127.0.0.1 with a nonsensical authority section delegating the root zone to localhost.. The correct behavior would be to return REFUSED for domains not configured on the server.

Even more weirdly, ClouDNS’ free nameservers correctly return REFUSED for domains they don’t host:

~$ dig google.com @ns4.cloudns.net. +noedns +norec

; <<>> DiG 9.18.28-1~deb12u2-Debian <<>> google.com @ns4.cloudns.net. +noedns +norec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 64552
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;google.com.                    IN      A

;; Query time: 251 msec
;; SERVER: 185.206.180.171#53(ns4.cloudns.net.) (UDP)
;; WHEN: Fri Apr 10 21:34:22 JST 2026
;; MSG SIZE  rcvd: 28

No aa flag, no bogus answer — just a clean REFUSED.

The exception is ns1.cloudns.net, which returns a false authoritative answer pointing to an actual working IP 185.105.32.123 instead – a catch-all landing page by ClouDNS:

~$ dig google.com @ns1.cloudns.net. +noedns +norec

; <<>> DiG 9.18.28-1~deb12u2-Debian <<>> google.com @ns1.cloudns.net. +noedns +norec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30787
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;google.com.                    IN      A

;; ANSWER SECTION:
google.com.             120     IN      A       185.105.32.123

;; AUTHORITY SECTION:
.                       120     IN      NS      localhost.

;; Query time: 272 msec
;; SERVER: 85.159.233.17#53(ns1.cloudns.net.) (UDP)
;; WHEN: Fri Apr 10 21:36:56 JST 2026
;; MSG SIZE  rcvd: 66

Note: As of April 2026, ClouDNS support replied: “At this time, the current behavior of our Premium nameservers is expected and no changes are planned.”

发布于

DMARC analytics services are expensive and aren’t really meant for individual use. Why not build one myself, now that we live in a world where Claude Code is so powerful? So I did.

Introducing DMARC Dashboard Kit.

发布于

Dev tips when making a Cloud Run service

  1. You can identify if your service is running on a Knative platform like Cloud Run by looking for the K_SERVICE environment variable.
    https://docs.cloud.google.com/run/docs/container-contract#env-vars
  2. When connecting to Cloud SQL, you should switch to IAM authentication and only use a connection string as a local fallback. Set a CLOUD_SQL_INSTANCE variable only in the deploy environment, and your application can detect this and use @google-cloud/cloud-sql-connector.
    https://docs.cloud.google.com/sql/docs/mysql/connect-connectors#node.js
  3. Correlate your container logs with a request log (services only)
    By default, container logs are not correlated with request logs. To link them without a client library like @google-cloud/logging, write a structured JSON log containing a logging.googleapis.com/trace field with the trace identifier extracted from the X-Cloud-Trace-Context request header.
    https://docs.cloud.google.com/run/docs/logging#writing_structured_logs
  4. Remember that Cloud Run is a serverless service, meaning instances can be scaled down at any time. If required, install a SIGTERM handler in your application to receive a warning when Cloud Run is about to shut down an instance. You will have a 10-second window to react.
    https://docs.cloud.google.com/run/docs/container-contract#instance-shutdown
  5. Cloud Run uses an in-memory file system, so every file you write to the instance is actually consuming your instance’s memory.
  6. Outbound network connections from Cloud Run can occasionally be terminated, either due to timeout or infrastructure restarts. If your application reuses long-lived connections, we recommend configuring it to re-establish connections to avoid reusing a dead connection.
  7. Cloud Run injects a PORT environment variable and expects your application to listen on it. Do not hardcode a port number (e.g. 8080); always read from process.env.PORT instead.
发布于

Compromised WordPress site

Today, I received a warning from Alibaba Cloud Security Center. A file scan reveals that wp-admin/network/theme-browse.php is likely a backdoor on one of the sites that I hosted. This article intends to record the findings and actions.

Immediately, I jump into confirming WordPress core’s integrity and confirm that these files should not exist:

$ wp core verify-checksums
Warning: File should not exist: wp-admin/network/test-file.php
Warning: File should not exist: wp-admin/network/manage-span.php
Warning: File should not exist: wp-admin/network/save-plugin.php
Warning: File should not exist: wp-admin/network/theme-browse.php
Success: WordPress installation verifies against checksums.

I can confirm that theme-browse.php is 100% malicious and points to a currently unavailable domain:

$switch="http://ink***ure.com/wp-includes/SimplePie/theme-captures.php?pl=2";

Action taken to reinstall all core files within wp-admin:

wp core download --force

Postmortem:

stat -c 'Path=%n
Modify=%y
Change=%z
Birth=%w
Owner=%U:%G
Perm=%a' theme-browse.php

Path=theme-browse.php
Modify=2016-03-29 14:45:30.000000000 +0900
Change=2026-01-30 12:21:27.858473359 +0900
Birth=2023-11-05 01:30:41.978928785 +0900

This shows that the file was inserted back in 2023, while the attacker backdated it to look like an old 2016 file. Further checks of my legacy backup files show that these files did exist as far back as at least 2020. Therefore, the 2016 timestamp may be correct, and the hosted site was likely exploited long before it was moved to my managed environment.