遠端主機上安裝的 Adobe Experience Manager 版本低於 2026.8.0、6.5.3。因此，會受到 APSB26-98 公告中所提及的多個弱點影響。

  - 在所有平台上的 Apache Tika tika-core (1.13-3.2.1)、tika-pdf-module (2.0.0-3.2.1) 和 tika-parsers (1.13-1.28.5) 模組中發現嚴重 XXE 漏洞。攻擊者可透過 PDF 內特製的 XFA 檔案，發動 XML 外部實體插入攻擊。此 CVE 涵蓋與 CVE-2025-54988 中相同的弱點。不過，此 CVE 受影響套件的範圍更大，原因有二。首先，雖然弱點的進入點是 CVE-2025-54988 中所報告的 tika-parser-pdf-module，但弱點及其修復卻位於 tika-core。已升級 tika-parser-pdf-module 但未將 tika-core 升級至 >= 3.2.2 的使用者，仍會受到影響。第二，原始報告未提及在 1.x Tika 版本中，PDFParser 位於 org.apache.tika:tika-parsers 模組。(CVE-2025-66516)

  - jackson-core 中的非封鎖 （非同步） JSON 剖析器不會強制執行 StreamReadConstraints 中定義的 maxNumberLength 條件約束 （預設值：1000 個字元）。能夠將 JSON 提交給使用非同步剖析器 API 的應用程式的攻擊者可以提供任意長度的數字權杖，從而導致過多的記憶體配置和潛在的 CPU 耗盡，進而導致拒絕服務。同步剖析器會正確執行此限制，因此根據應用程式使用的剖析 API 而套用限制不一致。根本原因：NonBlockingUtf8JsonParserBase 和相關類別中的非同步剖析路徑永遠不會叫用數字長度驗證方法。
    數字剖析方法 （例如 _finishNumberIntegralPart（） ） 會將數字累積到 TextBuffer 中，而不進行任何長度檢查，然後呼叫 _valueComplete（） 來完成權杖。_valueComplete（） 不呼叫 resetInt（） 或 resetFloat（），這是 ParserBase 中執行 validateIntegerLength（） 和 validateFPLength（） 的方法。因為會略過該驗證步驟，所以絕不會在非同步程式碼路徑上強制執行 maxNumberLength。影響：攻擊者若使用非同步剖析器將包含任意長數字的 JSON 文件傳送至應用程式 （例如 Spring WebFlux 或其他反應式應用程式），可導致 TextBuffer 中出現無限分配，並造成 OutOfMemoryError。如果應用程式隨後呼叫 getBigIntegerValue（） 或 getDecimalValue（），則 JVM 可能還會被綁定在 O（n^2） BigInteger 剖析中，從而造成基於 CPU 的拒絕服務。除了提交資料進行剖析的能力之外，不需要任何權限或使用者互動。此問題會影響 com.fasterxml.jackson.core：jackson-core 從版本 2.15.0 到 2.18.5 和從 2.19.0 到 2.21.0，以及 tools.jackson.core：jackson-core 從 3.0.03.0.x到 。之前 2.15.0 的版本不會受到影響，因為定義 maxNumberLength 設定的 StreamReadConstraints 是首次在 jackson-core 2.15.0中引入的，因此在早期版本中不存在此類約束可以繞過。請注意，GHSA-qq72hv-8253-57 將受影響 2.x 範圍的下限記錄為 2.0.0。（CVE-2026-18401）

請注意，Nessus 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

偵測

Adobe Experience Manager 6.5.0 < 6.5.3 / 2026.7.0 < 2026.8.0 多個弱點（APSB26-98）

medium Nessus Plugin ID 344294

版本 1.4

偵測

Adobe Experience Manager 6.5.0 < 6.5.3 / 2026.7.0 < 2026.8.0 多個弱點 （APSB26-98）

medium Nessus Plugin ID 344294

版本 1.4

Adobe Experience Manager 6.5.0 < 6.5.3 / 2026.7.0 < 2026.8.0 多個弱點（APSB26-98）