資安雷達 2026 年 8 月 16 日

2026-08-16 — Dancer2 認證外掛密碼重設連結遭 Host 標頭挾持,Perl DBI 模組兩起獨立堆積溢位漏洞同步在 1.652 版修補

primary=https://www.openwall.com/lists/oss-security/2026/08/15/4 primary=https://github.com/PerlDancer/Dancer2-Plugin-Auth-Extensible primary=https://github.com/perl5-dbi/dbi/security/advisories/GHSA-623j-hfpc-mrc4 primary=https://github.com/perl5-dbi/dbi/commit/29b72ae7d2a8114a734a55840bf1c45b89207809.patch primary=https://github.com/perl5-dbi/dbi/security/advisories/GHSA-wj3v-c3hh-mhqr primary=https://github.com/perl5-dbi/dbi/commit/c751ae5a5a6f56c2f8284f37c1f4d43500352ef1.patch

Dancer2 認證外掛密碼重設信件可遭偽造主機標頭挾持導向釣魚網域

oss-security 郵件列表 · 2026-08-15

Perl Web 框架 Dancer2 的認證外掛 Dancer2::Plugin::Auth::Extensible 於 2026 年 8 月 15 日透過 oss-security 郵件列表揭露一項密碼重設連結可被偽造主機挾持的問題,編號 CVE-2026-15689。受影響版本為 0.713 及之前所有版本。目前上游尚未釋出修補版本,僅提供組態層級的緩解建議。

漏洞機制

問題出在外掛內建的 _default_email_password_reset_default_welcome_send 兩個函式。這兩個函式在組出密碼重設信件與歡迎信件裡的連結時,直接採用請求端傳入的主機資訊,也就是 HTTP Host 標頭,或在應用程式設定 behind_proxy 時改採 X-Forwarded-Host。由於這些標頭完全由客戶端控制,攻擊者只需送出帶有偽造主機名稱的請求觸發密碼重設流程,系統寄出的信件連結就會指向攻擊者持有的網域。

對受害者而言,信件內容與正常重設信幾乎無異,差別僅在連結網域被置換。使用者一旦點擊該連結,重設用的一次性代碼就會落入攻擊者控制的伺服器,等同讓攻擊者取得完成密碼重設所需的憑證,形同帳號接管的前置步驟。同樣的邏輯也出現在新使用者的歡迎信件功能中,代碼外洩的後果相同。

受影響版本

  • Dancer2::Plugin::Auth::Extensible0.713(含之前所有版本)
  • 0.712 版起新增 uri_base 設定參數,用意是讓應用程式指定信任的網址前綴
  • 若未顯式設定該參數,程式仍會回退使用未經驗證的 request->uri_base

換句話說,即使升級到已內建緩解參數的版本,只要維運端沒有主動設定 uri_base,漏洞依然可被觸發。這也是此案例的關鍵:修補手段早已存在於程式碼中,卻不是預設安全(secure by default)。

修補與緩解

由於尚無新版本發布,目前的因應方式全部落在維運端設定。郵件列表原文建議:「set the uri_base configuration key to the application's own base URL; otherwise reject requests whose host is not an expected application hostname, including X-Forwarded-Host under behind_proxy.」換言之,管理者必須在設定檔中明確寫死 uri_base,或是在反向代理層擋下主機名稱不符預期的請求,兩者擇一才能避免連結被置換。

對於架設在 Nginx、Apache 等反向代理後方的部署,額外的緩解是直接在代理層限制或改寫 X-Forwarded-Host,不讓任意值傳入後端。這起漏洞也再次提醒,任何從請求標頭推導出的網址若被用於信件或重導向,都須視為不可信輸入來源並加以驗證。

原始來源:oss-security 郵件列表公告Dancer2-Plugin-Auth-Extensible GitHub 專案


Perl DBI 模組佔位符解析未驗證邊界,惡意 SQL 語句可觸發堆積寫入溢位

GitHub Security Advisory GHSA-623j-hfpc-mrc4 · 2026-08-15

Perl 資料庫存取核心模組 DBI 於 2026 年 8 月 15 日經 oss-security 揭露編號 CVE-2026-73194 的堆積緩衝區溢位漏洞,成因是 preparse() 函式處理數字型佔位符時未做邊界檢查。受影響版本為 1.652 之前所有版本,官方已在 1.652 版修補。

漏洞機制

preparse() 在展開類似 :p1:p2 的數字佔位符時,會先配置一塊輸出緩衝區,配置大小的假設是「每個輸入位元組最多對應 7 個輸出位元組」,也就是以 :p99999 這種六位數字佔位符為理論上限估算。問題在於解析佔位符編號時直接呼叫 atoi(src),卻沒有對結果做範圍檢查,導致像 :2147483648 這種輸入可以讓整數運算溢位,產生負數編號並繞過既有的邊界判斷。

一旦編號溢位成負值,後續 sprintf() 在展開該佔位符時實際寫出的字元數可達 13 個,遠超過原本每位元組預留的 7 個位元組。這使得寫入超出先前配置緩衝區的範圍,形成貨真價實的堆積緩衝區溢位,攻擊者可藉由精心構造的 SQL 陳述式觸發,安全研究者也以 AddressSanitizer 重現了此崩潰。

受影響版本

  • DBI < 1.652 均受影響
  • 修補版本:DBI 1.652
  • 觸發條件為應用程式中存在可被外部影響的動態 SQL 陳述式內容,且含有數字型佔位符語法

修補與緩解

1.652 版的修補作法是在 atoi() 取得佔位符編號後立即檢查範圍,超出上限或為零、負值時直接回傳錯誤並中止解析,而不是任由後續程式碼繼續展開。修補後的核心邏輯等同官方建議的邊界判斷式,關鍵新增程式碼如下:

if (pln > 99999 || pln <= 0) {
    char buf[99];
    sprintf(buf, "preparse found :p%d which is outside the allowed range.", pln);
    set_err_char(dbh, imp_xxh, "1", 1, buf, 0, "preparse");
    return &PL_sv_undef;
}

對於還無法立即升級的環境,唯一可靠的緩解是避免讓不受信任的輸入直接組成含數字佔位符的 SQL 陳述式字串,並儘速排入升級至 DBI 1.652 或之後版本的排程。

原始來源:GHSA-623j-hfpc-mrc4修補 commit 29b72ae7oss-security 郵件列表公告


DBI 模組緩衝區配置在 32 位元環境整數溢位,超長 SQL 陳述式可觸發堆積越界寫入

GitHub Security Advisory GHSA-wj3v-c3hh-mhqr · 2026-08-15

同一天,Perl DBI 模組還有另一項與 preparse() 有關但成因不同的堆積緩衝區溢位漏洞獲編號 CVE-2026-73193,同樣於 2026 年 8 月 15 日經 oss-security 揭露。此問題僅發生在 32 位元 Perl 建置環境,受影響版本同為 1.652 之前版本,修補版本也同為 1.652

漏洞機制

preparse() 配置輸出緩衝區時使用 newSV(strlen(statement) * 7 + 16) 這行運算,其中 strlen() 回傳型別 STRLEN 在 32 位元建置下只有 32 位元寬。當輸入的 SQL 陳述式長度超過約 6 億 1 千 3 百萬位元組時,乘以 7 的運算會在 32 位元整數範圍內溢位並回捲,導致計算結果遠小於實際需求,配置出遠小於預期的緩衝區。

後續的解析與展開流程不會因為緩衝區偏小而中止,而是繼續把完整輸入內容寫入這塊過小的緩衝區,形成攻擊者可控位元組的堆積越界寫入。以官方揭露內容為例,輸入若達到約 585MB 左右,該乘法計算即可回捲產生僅約 19 位元組的極小緩衝區,卻仍被要求寫入完整陳述式內容。64 位元建置由於 STRLEN 寬度足夠,須構造約 2.3 EB 的陳述式才可能觸發,實務上不具可行性。

受影響版本

  • DBI < 1.652,且僅限 32 位元 Perl 建置(如 Strawberry/ActiveState Windows、ARM32、舊版 i686 Linux)
  • 64 位元 Perl 建置不受影響
  • 修補版本:DBI 1.652

這起漏洞與同日揭露的 CVE-2026-73194 雖然都位於 preparse()、都在 1.652 版一併修補,但觸發條件、受影響平台與根因完全不同,分屬兩張獨立的 GitHub Security Advisory,不應混為一談。兩者差異整理如下:

項目CVE-2026-73194CVE-2026-73193
根因atoi() 佔位符編號未做邊界檢查STRLEN 乘法運算 32 位元整數溢位
觸發輸入形如 :2147483648 的超大數字佔位符長度逾約 613MB 的 SQL 陳述式
受影響平台不限位元寬度僅 32 位元 Perl 建置
GHSA 編號GHSA-623j-hfpc-mrc4GHSA-wj3v-c3hh-mhqr

修補與緩解

1.652 版的修補方式是在乘法運算前先把長度存到獨立變數並檢查是否超過安全上限(306783375 位元組),超過即回傳錯誤中止解析,避免溢位後的乘法結果被用來配置緩衝區。關鍵修補內容如下

int sln;
sln = strlen(statement);
if (sln > 306783375) { /* x * 7 + 16 would overflow maxint on 32bit ints */
    char buf[99];
    sprintf(buf, "preparse statement length exceeds maximum length (306783375).");
    set_err_char(dbh, imp_xxh, "1", 1, buf, 0, "preparse");
    return &PL_sv_undef;
}
new_stmt_sv = newSV(sln * 7 + 16);

在升級前的暫時緩解,官方建議 32 位元部署將 SQL 陳述式長度限制在 292MB 以下。由於此問題僅影響 32 位元建置,64 位元生產環境的維運團隊可將此列為較低優先序,但仍應與 CVE-2026-73194 一併排入 DBI 1.652 的升級計畫。

原始來源:GHSA-wj3v-c3hh-mhqr修補 commit c751ae5aoss-security 郵件列表公告


End of article
0
Would love your thoughts, please comment.x
()
x