【已落網 🫤】日本神戶發生一宗罕見的網絡犯罪案件，一對定居於當地的中國籍夫婦，涉嫌將小型電腦秘密藏於酒店客房雪櫃後方，藉由酒店的無線網絡（Wi-Fi）遠端發送近 48 萬封釣魚詐騙電郵，並利用盜取所得的他人信用卡資料進行高額消費。日本警方日前已將兩人拘捕，現正進一步調查背後是否存在跨國犯罪集團或幕後主腦。 根據日本警方透露，被捕疑犯為現年 39 歲的葉家豐（Ye Jiafeng）及其同齡妻子沈琦（Shen Qi）。案情指出，葉男於 2025 年 5 月 15 日夥同另一人假冒住客登記入住神戶市內一家酒店，並將一部小型電腦隱藏於客房雪櫃後方，隨後保持連接酒店的 Wi-Fi 網絡後離去。 hackread.com/phishing-emails… 犯罪手法之所以曝光，源於一名收到詐騙電郵的受害人發現信件追蹤資訊顯示出該酒店的 IP 位址，因而致電向酒店查詢。酒店職員接獲通報後展開內部排查，最終在客房雪櫃後方起獲該部運作中的 Mini PC，並隨即報警處理。 執法部門查扣該部電腦後進行數碼鑑識，發現機內儲存了約 240 萬組電郵地址，且已有約 48 萬封詐騙電郵成功發出。相關信件內容主要偽冒為知名信用卡發卡機構的官方通知，誘騙收件人點擊惡意連結進入高仿的假網站，藉此盜取受害人的信用卡號碼、到期日、安全碼及個人敏感資料。 警方初步調查研判，隱藏於雪櫃後的電腦實質上充當了代理或中繼發送站，是由其他共犯從外部進行遠端操控，利用酒店正常的商業網絡作為掩護向外散播詐騙郵件。 警方隨後搜查兩人的住所，當場扣押多達 74 部智能手機。進一步追查發現，兩人自 2024 年前後便開始利用盜得的信用卡資料進行非法消費，累計涉案金額至少達 1,000 萬日圓。

【恁爸出代誌 ⚠️】網域名稱註冊商兼憑證頒發機構 GoDaddy 日前爆出重大合規事故，旗下發行的 404,607 張 TLS/SSL 網站憑證，因內容與其公開發布的憑證政策與認證實踐聲明（CP/CPS）不符，違反業界基準規範，被要求必須強制全數撤銷。然而，受制於通知流程與系統處理量能，GoDaddy 未能在 CA/Browser 論壇規定的 5 天限期內完成撤銷程序；若受影響的網站管理員未及時下載並部署替換憑證，訪客瀏覽網站時恐將直接跳出「不安全連線」的全頁安全警告。 根據 Mozilla Bugzilla（Bug 2082703 與 Bug 2083191）公開的事故報告，本次問題最初由第三方資安研究人員通報，發現 GoDaddy 旗下體系發行的部分 TLS 憑證，其內部記載的憑證政策（Certificate Policy）資訊，包括特定物件識別碼（OID）與 CPS URI 限定條件，與官方對外公開的 CP/CPS 規範文件存在歧異。 tlsradar.com/blog/godaddy-ma… 儘管本次事故純屬發行端的合規設定失誤，並未涉及金鑰洩漏、網絡攻擊或 TLS 加密機制被破解，網站憑證在技術層面上亦能正常運作，但在 WebPKI 生態系中，憑證發行必須嚴格符合自身規範。依照 CA/Browser Forum 的《TLS 基準要求》（Baseline Requirements）第 4.9.1.1 條規定，當 CA 發現憑證未依據其 CP/CPS 正確發行時，必須於 5 天內全數撤銷。 受影響的 404,607 張憑證中，絕大多數屬於基礎的網域名稱驗證（Domain Validation, DV）憑證，其中僅 Starfield R1 DV 與 Starfield G2 DV 兩個中介 CA 體系便佔了 396,055 張，牽涉範圍極廣。 由於已經發行流通的 404,607 張問題憑證按法規無法原地修改，只能全數重新簽發並撤銷舊憑證。因數量龐大，GoDaddy 於 10 月 14 日開始透過電子郵件、短訊及電話向受影響客戶發出通知，並要求用戶儘速替換。然而，在 5 天撤銷寬限期屆滿時，GoDaddy 僅完成撤銷 170,566 張憑證，進度僅約 42.2%。截至 10 月 19 日清晨，撤銷數量推進至 227,422 張，仍有超過 17.7 萬張憑證尚未失效，因而正式向 Mozilla 提交了撤銷延誤的違規事故通報。 目前，GoDaddy 已決定大規模強制撤銷餘下尚未更換的 SSL/TLS 憑證，恐衝擊政府與金融網站。當局呼籲所有採用 GoDaddy 及 Starfield 憑證的網站管理員與企業 IT 人員，應立即登入後台確認憑證狀態。若系統提示憑證已重新簽發，必須即刻將新憑證下載並安裝至反向代理、負載平衡器（Load Balancer）、CDN 及 Web 伺服器等所有端點，以避免因憑證失效導致網上服務中斷。

【快更新 ⚠️】昨晚全球 IT 人打了一整晚的「丁」，今朝起身即被嚴重震撼。專案管理平台 GitLab 緊急發布重大安全性更新，修補一項 CVSS 評分高達滿分 10.0 的嚴重安全漏洞。攻擊者在特定條件下，無需取得任何登入權限，即可在自建伺服器（Self-managed Server）上遠端執行任意程式碼（RCE）。更引人關注的是，該漏洞影響範圍可追溯至 2014 年發布的 7.0 版本，波及長達 12 年來的所有釋出版本。   該漏洞編號為 CVE-2026-110264，屬於最高威脅等級。GitLab 官方指出，當系統編譯經過特殊構造的正則表達式（Regular Expression）時，可能引發整數溢位（Integer Overflow），進而使未經身份驗證的攻擊者取得遠端程式碼執行權限。   儘管 GitLab 尚未具體公開觸發該漏洞的前提條件，目前亦無跡象顯示此漏洞已遭黑客用於實際攻擊，但所有使用 GitLab 自建伺服器（Self-managed）的用戶仍需立即採取升級行動。   之所以會波及長達 12 年的歷史版本，問題根源在於 GitLab 所封裝的核心組件。該漏洞源於 Ruby 內建的正則表達式編譯引擎「Onigmo」，由於 GitLab 在自家的套件與建置環境中直接包含並維護該引擎，導致自 7.0 版以來的每一版 GitLab 均帶有此底層風險。   此漏洞由資安研究員「joaxcar」發現並回報。這已是該名研究員在短短一個月內，第四次在 GitLab 的正則表達式引擎中抓出程式碼執行漏洞。在此之前，GitLab 曾於 9 月 23 日修補需要登入權限的 CVE-2026-93577 與 CVE-2026-89078（CVSS 皆為 9.9），並於 10 月 12 日修補了同樣無需身份驗證的 CVSS 10.0 漏洞 CVE-2026-97229。但前三項漏洞的影響僅止於 19.2 版，本次漏洞影響則全面穿透至遠古版本。   如果你正在使用 GitLab，應立即更新至 19.0.10、19.1.9、19.2.9、19.3.6、19.4.3 或 19.5.1，7.0 至 18.11 版本的用家請更新至 18.11.13。官方強調，CVSS 10 分的漏洞等同見光死，除了「拔 Lan 線」之外沒有任何臨時緩解措施或配置規避方法，直接安裝修補版本是目前唯一可靠的防禦手段。