sashawebsite

2026 PHP 重大漏洞（PHP2Shell）完整說明：哪些網站會受影響、該怎麼處理？

Fri, 23 Oct 2026 13:12:49 GMT

2026 年 10 月 21 日，PHP 官方修補了兩個嚴重等級的漏洞（CVE-2026-109618、CVE-2026-109619，又被稱為 PHP2Shell），攻擊者不用登入，就有機會直接在你的網站主機上執行程式。

用 WordPress、WooCommerce、Drupal、Joomla、Magento 或其他 PHP 系統架的網站都在影響範圍內，建議盡快把 PHP 更新到 8.2.35、8.3.36、8.4.27 或 8.5.12 以上的版本。沒有使用 PHP 的架站平台（例如我們代理的 Duda Oasis）和純靜態網站，不受這次漏洞影響。

快速結論

漏洞編號為 CVE-2026-109618 與 CVE-2026-109619，PHP 官方給的 CVSS v4.0 評分皆為 9.2 分（嚴重等級）
兩者皆為遠端程式碼執行（RCE）漏洞，不需要登入帳號就能發動。
所有對外提供網頁服務的 PHP 環境都在範圍內；PHP 8.1 以下的舊版本，官方已經不再提供更新。
全球約 69.3% 的網站使用 PHP，WordPress、Drupal、Joomla、Magento 等系統皆受波及。
PHP 官方已於台灣時間 10 月 21 日晚上 10 點（14:00 UTC）釋出修補版本 8.5.12、8.4.27、8.3.36、8.2.35。
沒有使用 PHP 的網站平台（例如 Duda Oasis、Wix、Squarespace）不受此次漏洞影響。
換主機商解決不了這個問題，要更新的是 PHP 本身。

這次的 PHP 漏洞事件是什麼？

事件時間線

最麻煩的地方在於：官方還沒公布細節，攻擊工具就已經在流傳了。所以這次不能等「有空再更新」，越快越好。

我的網站有沒有受影響？一張表看懂

根據 W3Techs 的統計，全球約有 69.3% 的網站使用 PHP。許多主流的內容管理系統（CMS）與電商平台都是以 PHP 打造的，包括 WordPress（全球市占率最高的 CMS）、Drupal、Joomla、Magento，大量的共享主機服務也是以 PHP 為基礎環境。

換主機商可以解決這個問題嗎？

判斷方式很簡單：你的網站是不是跑在 PHP 上？

情況一：使用託管型主機服務

例如 GoDaddy 的 WordPress 代管、Bluehost、WP Engine 這類服務。PHP 版本通常由主機商統一管理，他們動作快，你就相對安全；動作慢，你只能等。

你該做的事 ：到主機後台確認目前的 PHP 版本，並查看主機商有沒有發布這次事件的公告。

情況二：自己租用 VPS 或雲端主機

包含自己在 AWS EC2、GCP、Linode 上架設的環境。 更新 PHP 是你自己的責任，沒有人會替你做。

這種情況的風險其實最高，因為很多網站架完之後就沒有人在維護了。

你該做的事 ：立刻登入主機，確認 PHP 版本，套用官方修補。

情況三：使用不含 PHP 的平台

這次的漏洞與你無關。

那麼 AWS 到底有沒有幫助？

有幫助，但幫的是另一件事。

AWS 在 10 月 21 日發布了安全公告，說明 AWS 自家的服務不受這兩個漏洞影響 。但如果你是自己在 AWS 上架主機、跑 PHP， PHP 還是要你自己更新 ，AWS 不會替你做。

AWS 沒辦法替你修補 PHP，但它的防護機制可以大幅降低「被攻擊打中」的機率。根據 AWS 資安長在官方部落格的說明：

自動偵測與阻擋 ：內部威脅情報系統會自動偵測並限制針對這個漏洞的惡意掃描行為
大規模事件分析 ：每分鐘分析超過 2,000 億筆事件
蜜罐網路情報 ：整合 MadPot 蜜罐網路的威脅情報，即時辨識並阻擋已知的漏洞利用攻擊
網站防火牆規則 ：AWS WAF（網站應用程式防火牆）也發布了針對這兩個漏洞的防護設定，在 PHP 更新完成前先擋下一部分攻擊

蜜罐系統的價值，在於能讓團隊在真的被打中之前，就 提早發現有人正在嘗試利用漏洞 。這次 AWS 就是在官方公布前 4 天，從蜜罐裡看到了第一筆攻擊嘗試。

所以正確的理解是： 修補漏洞是你（或主機商）的事，攔截攻擊是雲端平台能幫的忙。 兩者缺一不可。

我們代理的 Duda Oasis／WebCenter 狀況說明

我代理的是 Duda Oasis／WebCenter 平台，針對這次事件，這邊做完整說明。

Oasis 平台不受影響

根據平台方給代理商的說明， Oasis 的基礎架構本身並未使用 PHP ，因此這次的 CVE-2026-109618 與 CVE-2026-109619，不會影響到 Oasis 平台上的任何網站。

這跟我們反應快不快沒有關係：這個風險從一開始就不在架構裡。

託管環境

WebCenter 系統與客戶網站皆託管於 AWS。網站本身雖然不受這次漏洞影響，平台團隊與 AWS 在事件發生後，還是對整個託管環境做了檢查與安全更新。

檢查結果

平台團隊完成檢查與測試後， 未發現任何系統遭入侵的跡象 。Duda 官方的系統狀態頁也顯示，從 10 月 17 日第一筆攻擊嘗試出現到現在，所有系統都正常運作，沒有任何事故紀錄。後續團隊會持續監控狀況，必要時採取相應措施。

從這次事件，我想談談「網站的另外一半」

你看得到的，和你看不到的

常見問題

需要協助嗎？

如果你對自己網站的安全性、架構或現況有疑問，把網址傳給我，我幫你看一下現在這個時間點該不該調整，也會回一份簡單的網站健檢給你，內容包含網站基礎建置狀態，以及在 AI 的時代你的網站能不能跟上這個腳步。

這篇文章會說明：這次事件到底是什麼、哪些網站受影響、你該怎麼確認自己的網站安不安全，以及為什麼有一部分網站從頭到尾都不在風險範圍內。

這兩個漏洞的危險性在哪裡？

這兩個漏洞都屬於 RCE（Remote Code Execution，遠端程式碼執行）。

用白話來說：攻擊者有辦法在你的網站伺服器上，執行他自己想執行的程式，而且不需要先登入你的網站。

一旦成功，可能發生的事情包括：

竄改網站內容（例如植入廣告、導向詐騙頁面）
讀取或竊取資料庫（會員資料、訂單、聯絡資訊）
植入後門程式，長期潛伏在你的網站裡
把你的主機拿去當作攻擊其他網站的跳板

這也是為什麼 RCE 幾乎永遠是資安等級最高的漏洞類型。

不行，這是最常見的誤解。

漏洞存在於 PHP 這個程式語言本身 ，不在主機商那邊。把 WordPress 從 GoDaddy 搬到 AWS，漏洞會跟著一起搬過去，反過來也一樣。

真正決定你安不安全的，是 誰負責更新你網站上的 PHP 版本，以及更新得多快 。

哪些網站會受到影響？

大部分人在討論網站的時候，談的是視覺、文案、功能，這些都是看得見的部分。

但一個網站能不能長期穩定運作，很大程度取決於 看不見的那一半 ：程式架構、資安防護、主機維護、漏洞出現時的應變速度。

這些事不會讓網站變好看，也不會直接帶來訂單。可是一旦出事，前面花在網站上的時間和預算，就很難再回收了。

這次的 PHP 事件就是一個很具體的例子： 一個你從來沒想過的底層元件出問題，整個網站就可能被接管。

專業的事情，讓專業來

我做了十年以上的 UI/UX 設計，大多是公司內部用的系統。我很清楚自己擅長的是什麼：理解使用者的現況與問題，然後把它解決掉。

資安監控、伺服器維運、全球等級的威脅情報分析，就交給真正在做這件事的人。我做網站，但我不做程式開發，這也是我選擇代理 Duda Oasis／WebCenter 的原因之一：

底層交給真正在做這件事、而且有足夠規模去做的團隊
我負責 的是另外一塊：網站架構規劃、使用體驗、內容策略、品牌呈現

兩邊各自把自己的部分做好，客戶才會真的被服務到。

這對企業主的實際意義

如果你的網站是在 Oasis 平台上，這件事對你的意義是：

你不需要自己去判斷這次的 PHP 漏洞有沒有影響到你。

不需要查自己的網站跑在哪個版本、不需要擔心半夜伺服器被打、不需要出事之後才到處找人處理。

我認為一個網站服務真正該提供的保障，是在問題發生之前就有人顧著，像這次這樣，讓問題燒不到你身上。

如果你的網站正在使用 PHP，現在該做什麼？

即使你不是我的客戶，這幾件事還是建議立刻做：

確認 PHP 版本 ：登入主機後台或控制面板查看；WordPress 也可以在後台「工具 → 網站健康狀態 → 資訊 → 伺服器」看到
查看主機商公告 ：確認你的主機商是否已針對此次事件完成修補
立即套用更新 ：更新到 8.2.35、8.3.36、8.4.27 或 8.5.12 以上；還在用 8.1 以下的，要升級到新版本，或請主機商、維護廠商協助
檢查異常跡象 ：留意網站是否有不明檔案、不明管理員帳號、或異常導向；因為攻擊在官方公布前就出現了，建議從 10 月 17 日開始往後檢查
確認備份可用 ：確保你有一份近期、可還原的網站備份

如果以上這些你看不懂、也不知道該找誰處理，那其實就回到了這篇文章的核心問題： 你的網站，現在有人在替你守著嗎？

參考來源

詢價報價太花時間？5 人以下公司整理詢價流程的兩個步驟

Fri, 23 Oct 2026 11:09:57 GMT

我們接觸的客戶裡，有一家做消防器材的公司，不到 5 個人，在公寓一樓，地上擺滿各式各樣的消防產品，辦公桌也被大大小小的產品淹沒。

幾個人要同時顧理貨、出貨、看訂單、聯繫客人，還有報價。每張報價送出去之前，要先盤點庫存、確認客人講的到底是哪個品項，有時候還得回頭問老闆。客人問的東西，很多根本不在他們的網站上。

這個畫面我很熟悉，我們接觸的客戶有做五金批發的、做化學材料的，也有消防器材供應商。產業差很多，詢價卡住老闆的那一段卻很像。

這篇把我這段時間的觀察整理在一起：詢價為什麼特別花時間、時間漏在哪裡、整理詢價流程可以先從哪兩件事開始，以及網站在這中間能幫上什麼忙。

為什麼小公司的詢價報價特別花時間？

我們遇到的客戶，基本上都是 10 人以下的公司，人員分工沒辦法分得很細，很多時候一個人要做蠻多事情。

B2B 的詢價流程大多長這樣：客人對有興趣的產品（還有數量）來做詢價，公司再跟供應商確認價格，然後再回頭回覆客人報價。

拿五金零件商來說，常有空間設計、建商這類客人來問有沒有某些五金。助理或老闆要先確認品項，確認完再跟供應商問價格，最後才回覆客人。

聽起來很單純，最花時間的是最前面那段確認：客人講的品項公司有沒有、規格對不對、數量夠不夠。這些答案，常常只存在老闆的腦袋裡。

所以流程一亂，每一張詢價最後都會繞回老闆桌上。

詢價的時間，都漏在哪裡？

我看過的情況，大致可以整理成三個卡點。

一、入口太多，格式不一

電話一通、LINE 一則、網站表單一張，客人來問的方式非常多種，問法也非常多樣。有人填聯絡表單，有人懶得打字直接打電話，有人丟 LINE。

我也看過不少五金零件供應商的網站，有的一次只能問一個品項，有的全部都用制式的聯絡表單，客人只能把需要的產品名稱一個一個貼上去。客人填得很累，老闆收到之後還要一項一項確認，兩邊都在花冤枉時間。

二、品名對不上型號

品名最容易出事，名稱一樣、規格差一點點，就得再打一通電話確認一次。

我們有一位做五金零件批發的客戶，常常接到這樣的詢價：「我想詢問喇叭鎖的價格。」

問題是，光是叫喇叭鎖的，型號就有好幾種。鎖的樣子不同、鑰匙不同，型號就不同，客人講不出是哪一種，只能一來一回地問。

型號一對上，品項就不會搞錯，來回確認也會少很多。

三、管道開越多，越容易漏單

管道開越多，客人越方便，這句話我只同意一半。

同意的那一半，是客人想打電話就打、想傳 LINE 就傳，對他來說確實方便。另一半是，人手不夠的時候，沒辦法每個平台都顧到，就容易漏單。

5 人以下的公司很常見的畫面是：老闆在外面跑業務，LINE 有人問，網站表單又進來一張，辦公室電話也響過兩次，回到公司根本不知道該先看哪一個。

還有一種漏單更隱形，出在交接。老闆娘幫忙接了電話，老闆回了 LINE，同一個客人的詢價散在兩個人手上，最後兩個人都以為對方回了。

哪些報價還沒回、哪些處理到哪裡，甚至有一張報價單根本沒人處理，忙起來連老闆自己都不知道。

報價一慢，公司會損失什麼？

三個卡點加在一起，報價就會一路往後推。客人問完報價，如果等了三天，這三天他可能已經在跟別家聊了。

流掉的除了那一筆訂單，還有老闆花在對品項、追廠商的那些時間。

可以回頭算算看：上個月有幾張詢價，是報價還沒送出去，客人就先不見了？

人手不夠，多請一個人就能解決嗎？

最近常聽到老闆說，人手不夠，再請一個人就好了。老實說，我不會建議 5 人以下的公司一開始就先多請一個人～

品項有沒有、價格怎麼報，答案都在老闆的腦袋裡。新人接到詢價，還是要回頭問老闆：這個我們有沒有？那個是哪一款？老闆的時間沒省下來，反而多了一份薪水，還要花時間從頭教他認品項。

我過去十年都在做 SaaS 產品、企業內部系統的介面設計，每天處理的就是資料怎麼維護、流程怎麼跑順。那段經驗讓我很確定一件事：流程沒整理好，人加進來，只是多一個人一起亂。

人手不夠的時候，先補流程，再補人。公司人已經不多了，老闆的精力要留給談供應商、顧大客戶、想公司下一步，這些只有老闆能做的事。

整理詢價流程，可以先從哪兩件事開始？

如果我是一間 5 人以下公司的老闆，每天自己接詢價、自己問廠商、自己回報價，我只會先做兩件事。

第一步：把收詢價的窗口集中起來

入口可以留著，客人想打電話、傳 LINE、填表單都沒關係，只是最後都要收進同一個地方。不管是誰接的、從哪裡來的，打開就知道哪張報完了、哪張還卡著。

光是回想剛剛那個客人到底是在哪裡問的，就能耗掉半天。

第二步：定好一張詢價單的格式

品名、型號、數量，讓客人一開始就填成一樣的格式，老闆不用再一則一則追問。更好的做法是透過線上詢價工具，讓客人很自然地照著格式把需求送出來。

兩件事聽起來都很小，但亂源只要少一個，老闆每天就能多撈回一段時間，拿去談生意、想公司的下一步。

網站可以幫詢價流程做什麼？

最近也常聽到老闆說，公司想數位轉型，所以先把網站做起來了。

有網站確實踏出了第一步，接下來的第二步才是重點：這個網站能不能幫你把流程理順、讓更多事自動跑、減輕你的負擔。這才是做網站最根本的原因，好不好看、快不快、便不便宜，都排在後面。

很常見的畫面是，網站做得很漂亮，客人看完產品想詢價，還是得自己打電話、傳 LINE，老闆再一則一則對品項。網站換新了，老闆的工作量一點也沒少。

看過這幾個產業之後，我的立場很清楚：網站的最後一步，要讓客人很容易把需求一次送出來。客人邊逛邊把需要的產品收集起來，一次送出詢價，老闆收到的就是一張整理好的單。

前面提到的五金零件批發客戶，就是這樣做的。他們常去參展，每次都要印一疊 DM，品項一換又得重印。我們幫他們做了線上型錄網站，參展時直接給連結，對方看到的永遠是最新的品項。客人逛完把品項挑好、填上數量，一次送出，老闆收到的詢價有品名、型號、數量，看完就能報價。

詢價車跟購物車，差在哪裡？

如果你是做批發、代理的老闆，正準備做網站，想說讓客人在網站下單，那就弄個電商購物車吧，先問自己一個問題：你的價格，能在客人開口之前就標好嗎？

我們服務的客戶裡，有些要先問過供應商才報得出價格；也有些是全台獨家總代理，自己就能定價，只是不同數量有不同的價格級距。

兩種公司看起來差很多，最後卡在同一個地方：最終價格，要看完客人整張需求才決定得了。客人一次買好幾樣，可能要給一點折扣；遇到標案，就得想辦法報一個讓客人願意買單的價格。

電商購物車的設計邏輯，剛好跟這件事反過來。價格先標好，客人選完直接付款，所以要設定金流、物流，整個流程都在帶客人走向結帳，中間沒有一段是留給老闆看完需求、再決定怎麼報的。

詢價車走的是另一條路，客人邊逛邊把要的品項、數量收集起來，一次送出，老闆收到的是一整張需求，看完再決定這一單怎麼報最有競爭力。

網站先幫你把整張需求收齊，這一單怎麼報才能讓客人點頭，那是老闆的功夫，留在你手上就好。

做線上型錄，產品分類越多越好嗎？

我們很常遇到這種老闆：看到同業網站有什麼，就想要什麼。產品分成大、中、小三層，再加品牌分類、應用情境分類，切面越多越安心。

對逛網站的客人來說，分類多確實有幫助，但每多一種分類，就多一份要維護的工作。

5 人以下的公司，不可能天天顧商品。上架一個新品，可能有五、六個區塊要跟著同步新增，忙起來新品放不上去，舊品也來不及下架，網站就越來越跟不上公司的實際狀況。

所以我們不會一味滿足所有需求，會先挑出最重要、客人最想看的內容。決定要放哪些分類之前，可以先問自己三個問題：

客人找產品時，最常用什麼找？型號、品牌，還是用途？
新品上架時，這個分類誰來顧？一週撥得出多少時間？
拿掉這個分類，客人會找不到東西嗎？

三題都答得出來，這個分類就留著；有一題卡住，就先放著，等公司有餘力再加也不遲。

老闆可以先問自己的 5 個問題

想知道自己公司的詢價流程卡在哪裡，可以先從這幾題開始：

你的公司現在開了幾個詢價入口？又有幾個人在顧？
客人問完報價，通常要等幾天才收到回覆？
上個月有幾張詢價，是報價還沒送出去，客人就先不見了？
客人來詢價時，會講型號嗎？
新人接到詢價，能不能不問你就回答？

有兩題以上答不太出來，就很值得花一點時間，先把詢價流程整理一輪。

常見問答

網站上線那天，整理才剛開始

接下來要看的，是網站每天能幫你分擔多少事。

如果你的公司也是詢價從四面八方進來，每一張最後都繞回自己桌上，歡迎聯繫我們聊聊你的產品跟報價方式，讓我協助你一起看看，哪些事可以先從你手上移開～

sashawebsite

2026 PHP 重大漏洞（PHP2Shell）完整說明：哪些網站會受影響、該怎麼處理？

快速結論

這次的 PHP 漏洞事件是什麼？

事件時間線

我的網站有沒有受影響？一張表看懂

換主機商可以解決這個問題嗎？ ﻿

情況一：使用託管型主機服務 ﻿

情況二：自己租用 VPS 或雲端主機 ﻿

情況三：使用不含 PHP 的平台 ﻿

那麼 AWS 到底有沒有幫助？ ﻿

我們代理的 Duda Oasis／WebCenter 狀況說明 ﻿

Oasis 平台不受影響 ﻿

託管環境 ﻿

檢查結果 ﻿

從這次事件，我想談談「網站的另外一半」 ﻿

你看得到的，和你看不到的 ﻿

常見問題 ﻿

需要協助嗎？ ﻿

這兩個漏洞的危險性在哪裡？

哪些網站會受到影響？

專業的事情，讓專業來 ﻿

這對企業主的實際意義 ﻿

如果你的網站正在使用 PHP，現在該做什麼？ ﻿

參考來源 ﻿

詢價報價太花時間？5 人以下公司整理詢價流程的兩個步驟

為什麼小公司的詢價報價特別花時間？ ﻿

詢價的時間，都漏在哪裡？ ﻿

一、入口太多，格式不一 ﻿

二、品名對不上型號 ﻿

三、管道開越多，越容易漏單 ﻿

報價一慢，公司會損失什麼？ ﻿

人手不夠，多請一個人就能解決嗎？ ﻿

整理詢價流程，可以先從哪兩件事開始？ ﻿

第一步：把收詢價的窗口集中起來 ﻿

第二步：定好一張詢價單的格式 ﻿

網站可以幫詢價流程做什麼？ ﻿

詢價車跟購物車，差在哪裡？ ﻿

做線上型錄，產品分類越多越好嗎？ ﻿

老闆可以先問自己的 5 個問題 ﻿

常見問答 ﻿

網站上線那天，整理才剛開始 ﻿