CVE-2026-112917

Running AI agents or dev containers on Windows? A container in Docker Desktop for Windows (CVE-2026-112917) can slip past the WSL 2 vsock block and reach your Windows files. The fix needs 4.98.0 plus WSL 3.0.3+. Run wsl --update, then wsl --shutdown. https://hol.org/blog/cve-2026-112917-docker-desktop-wsl2-vsock-isolation-bypass https://t.co/JbQlGbnzsa

🚨 Windows’ta Docker Desktop kullanıyorsanız bu güncellemeyi ertelemeyin. CVE-2026-112917 (CVSS 9.2), WSL2 kullanan x86-64 sistemlerde ayrıcalıksız bir Linux container’ın izolasyon kısıtlamasını aşmasına imkân tanıyor. Sonuç: bilgisayarınızdaki servislere ve oturum açmış kullanıcının erişebildiği Windows dosyalarına erişim riski. Açığı kapatmak için İKİ güncelleme gerekiyor: → Docker Desktop 4.98.0 veya üstü → WSL 3.0.3 veya üstü PowerShell’de sırasıyla: wsl --update wsl --shutdown Ardından Docker Desktop’ı yeniden başlatın. WSL sürümünüzü wsl --version ile kontrol edin. Yalnızca Docker Desktop’ı güncellemek yeterli değil. https://docs.docker.com/desktop/release-notes/

Install the latest Docker Desktop security update to patch two critical Docker Desktop vulnerabilities, including container escape flaw CVE-2026-112917. #Docker #DockerDesktop #ContainerSecurity #WSL2 #CVE2026112917 #LinuxKernel #InfoSec #Cybersecurity https://meterpreter.org/docker-desktop-vulnerabilities-cve-2026-112917/

🔥 CyberForge CVE of the Day #095 🚨 CVE-2026-112917 — Docker Desktop / WSL2 isolation bypass Docker's fix has two parts: Docker Desktop 4.98.0+ AND WSL 3.0.3+. New Desktop with older WSL remains affected. On Windows x86-64 WSL2 hosts, code in an unprivileged Linux container can bypass the default AF_VSOCK restriction through 32-bit socketcall, exposing host-facing capability and potentially the logged-in user's accessible files through a reachable host-side service. ⚠️ Scope applicable developer endpoints and verify both active components. 🎯 The quick hit: What is happening? Docker reports an alternate syscall route around default container isolation on Windows x86-64 WSL2. The attacker starts with code in an unprivileged container. Who checks? Desktop/endpoint owners: identify the actual backend, Desktop product version, WSL application and active kernel. LinuxKit-based backends are unaffected by this CVE. Why care? Host-facing services and the logged-in user's accessible files may be exposed; file access needs the reachable host-side AF_VSOCK service. No universal Administrator/SYSTEM access is established. Start with: owner and scope → preserve useful history → restrict suspect workloads as warranted → update both components. Follow the evidence: exact container and endpoint → user/UTC context → host-side service → independently corroborated result. Escalate: unapproved host operations linked to an applicable endpoint and suspect workload. Exposure alone does not prove compromise. Watch the gaps: transport/file-read visibility, normal developer sharing, and an update record naming only one component. 🔑 Key details: ⭐ Severity: Docker CNA Critical. 📊 CVSS: v4.0 Base 9.2, assessed by Docker. 🧮 Vector: `CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:H/SI:H/SA:N` 🧠 Weakness: CWE-424 — Improper Protection of Alternate Path. 🎯 Product / component: Docker Desktop for Windows, WSL2 backend, x86-64 host; stock WSL kernels have 32-bit syscall compatibility enabled according to the CNA. 🧩 Boundary: unprivileged container code → default seccomp AF_VSOCK restriction → host-facing capability. 🔓 Starting access: code running in an unprivileged Linux container; published AV:L / PR:L. No privileged-container or mounted-Docker-socket prerequisite is stated for this issue. 👆 User interaction: None in the published vector. That does not explain how malicious code first reached the container. ⚔️ Capability: host-facing services and user-accessible Windows files may be exposed. Host-file access requires a reachable host-side AF_VSOCK service. No particular service or port is named. 🛡️ Full correction: Desktop 4.98.0+ AND WSL 3.0.3+. The CNA identifies WSL kernel 6.18.54.1; reconcile the supported active kernel, especially if a custom kernel is configured. 🚨 Activity: CISA ADP's SSVC assessment, dated 3 November, records exploitation none, automatable no, technical impact total. This is an attributed assessment, not proof of universal absence. 🧪 Public PoC: not verified in the reviewed primary references and exact-ID discovery. The review was not an exhaustive exploit-repository survey; no exploit was executed. 📋 KEV: no exact match in captured CISA catalog 2026.11.03, released 2026-11-03T20:00:24.8741Z, containing 1,767 entries. 📉 FIRST EPSS: exact query returned HTTP 200 with `total: 0`, `data: []`. Probability, percentile and score date are unavailable, not zero. 🏷️ Credits: Oryam Halachmi and Tevel Halachmi of Deune, credited by Docker's CNA. NVD was Received. Its v4.0 score is sourced to `security@docker.com` with role Secondary, not independently scored by NIST. NVD expands undefined optional metrics with `X`; the base assessment remains Docker's. No v3.x score was supplied in the captured CNA/NVD metrics. 🧬 What actually went wrong? Seccomp restricts Linux system calls and selected arguments. Docker's guidance explains that filtering `socket` arguments does not cover `socketcall`; the CVE supplies the Windows WSL2 scope and impact. The defensive sequence: 1. Code already runs in an unprivileged container on an applicable endpoint. 2. The compatible 32-bit interface bypasses the default AF_VSOCK restriction. 3. Host-facing capability becomes reachable as described by Docker. 4. Windows file exposure additionally needs a reachable host-side AF_VSOCK service and is bounded by the logged-in user's access. AF_VSOCK is host/guest communication, not ordinary TCP/UDP exposure. Confirm a control or sensor actually covers the transport before relying on it. Evidence boundary: vendor-reported mechanism, corroborated at release level. No exact security diff or exploit reproduction was validated here. No Windows administrative execution, actor, victim, persistence or exfiltration is established. 📦 Which deployments belong in scope? 🔴 Windows x86-64 WSL2 Desktop below 4.98.0: affected scope; new WSL alone does not meet the remedy. 🔴 Desktop 4.98.0+ with WSL below 3.0.3: explicitly remains affected. 🟢 Published correction: Desktop 4.98.0+ together with WSL 3.0.3+ and supported active kernel state. This is a criterion, not a finding on an examined machine. Exception: LinuxKit-based backends are unaffected. Confirm the real backend; a generic Hyper-V/VMM/ECI label is not case-specific acceptance. Other platforms are outside this report's published scope or unassessed, without a broad safety verdict. Data caveat: the CNA's structured Desktop row starts its unaffected range at 4.98.0; prose/configuration imposes the WSL condition. Keep both; a Desktop-only rule can miss the affected older-WSL pair. Inventory: Desktop product, Engine, CLI plugin, WSL application, WSL generation and kernel versions are distinct. Image updates do not update the host pair. Remote contexts can describe another machine. Custom kernels require active-build/fix evidence. 🕰️ Exposure window and timeline: 6th October 2026: Microsoft kernel 6.18.54.1 release published at 22:28:50Z. 9th October: WSL 3.0.3 published at 18:21:40Z with that kernel dependency. 19th October: CVE reserved; not a discovery date. 3rd November: Docker 4.98.0 security release; CVE published at 19:08:11.422Z. 4th November: record/ADP and NVD updates captured before cutoff. These dates do not establish first exploitation or local installation. Bound a hunt from evidenced affected state and suspect workload activity to verified correction/containment, extending for justified consequences. Record uncertain earlier history, retention, clocks and container replacements. 🗺️ MITRE ATT&CK: Conditional CyberForge assessment: Privilege Escalation / TA0004 → T1611 Escape to Host is useful for the vendor-reported movement from a container isolation boundary to host-facing capability. Basis: Docker's CVE supplies the behaviour and prerequisites; MITRE supplies the technique definition. This is not an observed intrusion mapping. The tactic name does not establish Windows Administrator/SYSTEM access. Defender pivot: relate exact container and endpoint state to a corroborated unauthorised host operation. Establish which guest/transport and host-result sources actually cover the interval, then record alternatives and missing visibility. Reference: Enterprise ATT&CK v20; T1611 version 1.6, last modified 24 October 2025; checked 4 November 2026. Mapping limit: no initial-access route, actor, credential theft, persistence, lateral movement or exfiltration technique is inferred. One justified mapping is more useful than an invented chain. 🧭 SOC investigation trail: Objective: determine whether a suspect container on an applicable endpoint reached a host-side service or caused an unauthorised host-file operation. These are proposed checks, not findings. Scope: approved endpoints/workloads and a justified UTC interval. Confirm permissions, historical source health and clocks. Preserve stable device/container identities and process-creation context; names and PIDs can be reused. C01 — Applicability and reachability Action / location: endpoint owner collects Desktop product version, actual backend, architecture, WSL package/kernel and change history. Workload owner identifies daemon/context and container; identify the actual host-side service for a file-access question. Signal / correlate: device, time, both components, active kernel and service scope agree. Benign causes / limits: stale inventory, inactive updates, remote contexts and custom kernels can mislead. Escalate: unmet joint correction to change owner; suspect workload plus host-result evidence to SOC/IR. No local assessment here. C02 — Starting workload and access context Action / location: preserve existing lifecycle/provenance, build/run and relevant runtime/service records through approved exports. Signal / correlate: unexplained workload execution near an unapproved host operation; join exact instance, daemon, endpoint, user and UTC context. Preserve actual image identity, not only a mutable tag. Benign causes / limits: normal builds/helpers/integration; Docker events returns only the last 256 events and not every syscall. Escalate: suspicious workload with corroborated host activity warrants triage. No container was queried or entered here. C03 — Host-side outcome Action / location: service/data owner examines operation, target, user permissions and actual result; seek independent file/application evidence. Signal / correlate: applicable endpoint/workload → service operation → unapproved outcome, with record IDs and authorisation context. Benign causes / limits: approved sharing, sync, builds and Windows-native processes; Sysmon Event 11 covers create/overwrite, not all reads. CNA names no universal service/schema. Escalate: corroborated outcome to IR; ambiguity to follow-up; missing history to a visibility gap. A changed file alone does not identify this CVE. C04 — State transitions Action / location: compare Desktop/WSL updates, backend/kernel and service/access changes with authorised change history. Signal / correlate: endpoint state transition and suspect interval; distinguish original event from inventory refresh. Benign causes / limits: planned maintenance and developer experiments. This CVE bypasses a default restriction; disabling seccomp is not a stated prerequisite. Escalate: resolve contradictions with platform owner; corroborated unapproved changes to SOC. No settings changed here. C05 — Conditional follow-on Action / location: only if service/file evidence justifies it, scope a specific credential, source artifact or resource with its owner and existing audit records. Signal / correlate: independently recorded unapproved use/change linked to the earlier event. Benign causes / limits: ordinary account use and automation; no credential theft, destination or supply-chain compromise attributed in the primary material. Keep secrets private. Escalate: widen on supported consequences or a recorded incident decision. Plan only. C06 — Both corrections active Action / location: change owner records active Desktop ≥4.98.0, WSL ≥3.0.3, supported kernel/backend and benign workload health for every in-scope endpoint. Signal / correlate: trusted product inventory, runtime and change/restart record agree; review custom kernels separately. Limits: partial rollout, stale VM or rollback can leave exposure; correction does not answer historical data/credential questions. Escalate: unmet acceptance to change owner, continuing anomalies to IR, missing history to an owned gap. No update installed/tested here. The analyst handover: Record asset/owner → UTC window → source/record IDs → observation → alternatives/gaps → next action/owner. Separate applicability, exposure, suspicion, corroborated outcome and insufficient telemetry. A no-match needs examined sources, predicates, caps and retention; it cannot clear an unobserved transport or file-read path. 🔎 Indicators and observable behaviour: No confirmed CVE-specific malicious address, domain, hash, filename, port or universal log signature was supplied in the reviewed primary references. Do not invent indicators to populate a hunt. Useful behavioural leads are an applicable component/backend state, suspect container execution, an unexplained host-service operation and a corroborated unapproved file result. Each needs provenance and normal-workflow review. Microsoft documents Sysmon Event 3 as TCP/UDP connection telemetry, disabled by default, and Event 11 as file creation/overwrite. Sensor presence alone does not establish relevant transport coverage, all file reads or historical retention. 🧰 Optional CVE checks: These are documentation checked only; not run on Windows, Docker or WSL. No PowerShell parser or detector test is claimed. Keep raw results private with endpoint, UTC, execution identity, tool/version, exit status and errors. Check A — Identify the WSL side of the remedy On one approved Windows endpoint, run locally in PowerShell or Command Prompt: ```powershell wsl --version wsl --status wsl --list --verbose ``` Interpret: version reports WSL/component information; status gives configuration/kernel context; list shows distribution state and WSL 1/2 generation. Compare the WSL application against 3.0.3, reconcile the supported active kernel, and separately verify Desktop product 4.98.0+ through About/trusted product inventory. Limit: an unsupported option, error or missing field is a collection gap. “VERSION 2” is not “WSL 3.0.3.” Installed metadata does not prove active correction or an incident outcome. https://learn.microsoft.com/en-us/windows/wsl/basic-commands Check B — Inspect one approved context Purpose: avoid treating a remote daemon as the Windows endpoint. With an approved existing Docker CLI in PowerShell: ```powershell $cfApprovedContext = Read-Host 'Enter one approved Docker context name' if ([string]::IsNullOrWhiteSpace($cfApprovedContext)) { throw 'An approved context name is required.' } docker context inspect "$cfApprovedContext" ``` Interpret / correlate: review the named context and endpoint configuration before any separate container inspection. Retain the chosen context with subsequent queries; a familiar name alone is insufficient. Output can contain private paths/endpoints. Limit: unknown context and CLI errors remain failures. Context metadata is not a Desktop product version, active backend or proof of exploitability. No daemon/container was changed or queried here. https://docs.docker.com/reference/cli/docker/context/inspect/ Shortcut excluded: `docker desktop version` is documented as the Desktop CLI plugin version. It cannot establish the installed Desktop 4.98.0 product. https://docs.docker.com/reference/cli/docker/desktop/version/ 🩹 Remediation and verification: 1⃣ — Establish scope and control exposure. Confirm the actual endpoint/backend and both component states. Restrict suspect/untrusted workloads through the responsible owner where warranted; this is opportunity reduction, not a substitute fix. 2⃣ — Preserve relevant history where feasible. Retain useful lifecycle, service, host-result and change records before restart/rotation. Do not delay urgent containment for an ideal collection set. Product diagnostics may contain sensitive data; no support upload is implied. 3⃣ — Complete the joint correction. Use supported vendor channels for Docker Desktop 4.98.0+ AND WSL 3.0.3+. The CNA references WSL kernel 6.18.54.1. Do not call either update alone the full fix. 4⃣ — Verify active state and health. Reconcile trusted Desktop product identity, WSL package, active supported kernel/backend, any required owner-managed restart and benign workload checks. Microsoft notes that WSL shutdown terminates all distributions and the utility VM, so plan changes deliberately. 5⃣ — Resolve consequences separately. If evidence supports relevant file, credential or artifact exposure, scope response with the data/identity/incident owner. An update does not undo an earlier unauthorised action. Temporary-control limit: CNA says LinuxKit-based backends are unaffected; any proposed alternative-backend route needs support, actual backend and workload/data validation. No generic firewall, ECI or custom seccomp policy is certified here as an equivalent remedy. Keep seccomp restrictions enabled. Completion: both corrected components active, scope reconciled, workload health acceptable, exceptions owned, and a bounded historical incident/visibility disposition recorded. 🧾 Evidence separation: Vendor / official: Docker CNA scope, capability, score, joint fix and credits; Docker/Microsoft release evidence; dated CISA/FIRST responses. Researcher / incident: CNA finder credits retained; no separate primary victim/campaign report or working PoC verified in this bounded review. CyberForge: priority, proposed SOC checks, conditional T1611 mapping and acceptance questions. Not established: local exposure, host service reach, malicious outcome, installed correction, detector effectiveness or incident recovery. Artifact validation cannot supply those findings. 🔥 CyberForge verdict: CVE-2026-112917 matters because an alternate interface can undermine an intended container boundary on a specific developer-host configuration. Priority: scope applicable Windows x86-64 WSL2 endpoints and complete the supported joint update, prioritising suspect/untrusted workloads and sensitive user context. Keep public severity, attributed activity and local evidence distinct. Defender order: identify both active components → preserve and correlate useful history → correct both → verify running state → resolve any host-side consequence. The decision that matters: a product update and a dependency update must agree on the same endpoint; an incident conclusion needs independent evidence of what happened. > Close the alternate path, verify both components, and let host-side evidence decide the incident. 🔗 Sources and further reading: Docker correction: https://docs.docker.com/desktop/release-notes/#4980 Microsoft WSL release: https://github.com/microsoft/WSL/releases/tag/3.0.3 Kernel dependency: https://github.com/microsoft/WSL2-Linux-Kernel/releases/tag/linux-msft-wsl-6.18.54.1 Docker CNA record: https://cveawg.mitre.org/api/cve/CVE-2026-112917 NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-112917 MITRE T1611: https://attack.mitre.org/techniques/T1611/ KEV feed: https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json FIRST exact query: https://api.first.org/data/v1/epss?cve=CVE-2026-112917 Docker event-history limit: https://docs.docker.com/reference/cli/docker/system/events/ #CyberSecurity #CVE #BlueTeam #ThreatHunting #SOC #CyberForge #Docker #WSL2

🆕 New CVE Docker Desktop: isolation bypass in AF_VSOCK seccomp filter (CVE-2026-112917) An unprivileged Linux container can reach host-facing services and read Windows files the logged-in user can access. No patch listed yet https://cve.now/CVE-2026-112917?utm_source=x&utm_medium=social&utm_campaign=cvedotnow&utm_content=critical

Docker Desktop for Windows flaw: containers can reach host files Update to Docker Desktop 4.98.0 and WSL 3.0.3. CVE-2026-112917 (CVSS 4.0 9.2, CNA): an unprivileged container on the WSL 2 backend can bypass the AF_VSOCK seccomp block. 4.98.0 on older WSL stays affected. Exploitation not stated. https://docs.docker.com/desktop/release-notes/ #Docker #CVE

【11/4 朝】CVE・脆弱性ニュースまとめ ■国内 4日朝の時点で、国内ベンダー製品やJVN・IPA・JPCERT/CCの注意喚起で、新たに対象となるものはありませんでした。 ■海外 ① WordPress「WordPress本体」（続報）：本体の更新中にログインなしでコードを実行されうる脆弱性を、米CISAが悪用確認済みとしてKEVに追加（CVE-2026-119977、CVSS v3.1 8.1） 10月31日に取り上げた、WordPress本体を「完全パッケージ」で更新する数秒間に、展開中のファイルを狙ってサーバー上でコードを実行されうる競合状態の脆弱性について、米CISAが3日（米国時間）に悪用確認済み脆弱性カタログ（KEV）へ追加しました。CVEの記録にもCISAによる「悪用あり（active）」の評価が付いており、米連邦機関には11月6日までの対応が求められています。CISAは具体的な被害の内容は明らかにしていません。影響は4.7〜7.1.3で、10月28日公開の7.1.4（4.7系まで各系列にも修正を提供）で修正されています。自動更新が止まっているサイトは、すぐにバージョンを確認して更新してください。 出典：CVE記録 https://www.cve.org/CVERecord?id=CVE-2026-119977 出典：WordPress https://wordpress.org/news/2026/10/wordpress-7-1-4 出典：CISA KEV https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2026-119977 ② Google「Chrome」：Chrome 157の安定版で213件の脆弱性を修正、うち7件がCritical（CVE-2026-121156ほか、CVE記録のCVSS v3.1 9.6） Googleが3日（米国時間）、Chrome 157をWindows、Mac、Linux向けの安定版として公開し、213件のセキュリティ修正を含むと発表しました。Criticalと評価されたのは、Dawn（WebGPUの実装）のバッファオーバーフロー（CVE-2026-121156、CVE-2026-121247）、ANGLE（グラフィックス処理）のメモリ破損（CVE-2026-121229）、WebGL・Prerender・Geometry・Coreの解放後使用（CVE-2026-121246、CVE-2026-121035、CVE-2026-121203、CVE-2026-121126）の7件です。CVEの記録では、細工したWebページを開くだけで、サンドボックスの外でコードを実行されるおそれがあるものが含まれています。修正版はLinuxが157.0.8103.38、Windows・Macが157.0.8103.38/39で、今回の発表には実際の悪用に関する記載はありません。順次配信されるため、メニューの「Chromeについて」から更新と再起動を確認してください。 出典：CVE記録 https://www.cve.org/CVERecord?id=CVE-2026-121156 出典：Chrome Releases https://chromereleases.googleblog.com/2026/11/stable-channel-update-for-desktop.html ③ SolarWinds「Dameware（リモート操作・保守ツール）」：遠隔操作先の端末を乗っ取られうるコマンドインジェクション（CVE-2026-28336、CVSS v3.1 9.9） 社内PCのリモートサポートに使われるDamewareで、コマンドインジェクションの脆弱性が3日に公表されました。SolarWindsによると、悪用には認証が必要ですが、成功すると遠隔操作されている側の端末が乗っ取られるおそれがあります。対象は2026.3以前のすべてのバージョンで、2026.3.1で修正されています。同時に、認証後のバッファオーバーフロー（CVE-2026-28335、CVSS 8.4）なども修正されました。現時点で悪用の報告は確認できていません。 出典：CVE記録 https://www.cve.org/CVERecord?id=CVE-2026-28336 出典：SolarWinds https://www.solarwinds.com/trust-center/security-advisories/CVE-2026-28336 ④ HPE「HPE Networking Fabric Composer（データセンターのネットワーク管理）」：ハードコードされたパスワードで、ログインなしに管理者権限を奪われうる脆弱性など（CVE-2026-95731、CVSS v3.1 9.8／CVE-2026-95732・CVE-2026-95733、9.6） HPEが、データセンターのスイッチ群をまとめて管理するFabric Composer（AFC）について、複数の脆弱性を公表しました。CVE-2026-95731はCLIに埋め込まれたパスワードの問題で、ログインしていない遠隔の攻撃者が管理者権限でシステムに入れてしまうおそれがあります。CVE-2026-95732とCVE-2026-95733は、同じネットワーク内の攻撃者が認証なしで任意のコードを実行できてしまう問題です。対象は7.4.0以前と7.3.4以前で、修正版は7.4.1以降と7.3.5以降です。HPEは社内の調査で見つけたもので、公開された攻撃コードは把握していないとしていますが、管理画面とCLIを専用の管理用ネットワークに限定するよう勧めています。 出典：CVE記録 https://www.cve.org/CVERecord?id=CVE-2026-95731 出典：HPE https://support.hpe.com/hpesc/public/docDisplay?docId=hpesbnw05172en_us&docLocale=en_US ⑤ SonicWall「GMS（Global Management System、ファイアウォールの統合管理）」：ログインなしで内部ファイルを読まれうる脆弱性、サポート終了製品のため修正版なし（CVE-2026-109593、CISAによる評価CVSS v3.1 9.1） SonicWallのファイアウォールをまとめて管理するGMSで、ネットワーク越しに届く攻撃者が、ログインせずにGMS内部のファイルを読み取り、機密情報を得られるおそれがある脆弱性が公表されました。あわせて、ログイン後のSQLインジェクション（CVE-2026-109594）も公表されています。対象は9.5.2以前で、SonicWallの勧告は「サポート終了（EOL）のGMS」が対象とする内容で、修正版の案内は確認できていません。現時点で悪用の報告は確認できていませんが、使い続けている場合はインターネットから届かないようにしたうえで、後継製品への移行を検討してください。 出典：CVE記録 https://www.cve.org/CVERecord?id=CVE-2026-109593 出典：SonicWall https://psirt.global.sonicwall.com/vuln-detail/SNWLID-2026-0019 ⑥ Perforce「Puppet Enterprise（サーバー構成管理）」：エージェント証明書を持つだけで、Puppet Server上でコードを実行されうる脆弱性など2件（CVE-2026-115731、CVSS v4.0 9.4／CVE-2026-115732、9.0） 多数のサーバーの設定を自動で管理するPuppet Enterpriseで、2件の脆弱性が公表されました。CVE-2026-115731は、エージェントが送るレポートの処理に不正なデータを読み込んでしまう問題があり、認証局が署名したエージェント証明書を1枚でも持っていれば、Puppet Server上で任意のコードを実行できてしまうおそれがあります。証明書の発行を十分な確認なしに自動承認（autosign）している環境では、ログインしていない攻撃者でも証明書を手に入れられるとしています。CVE-2026-115732は証明書の名前の照合が甘く、似た名前の証明書で別のノードになりすませる問題で、Enterprise版では認証局の管理や管理対象ノードでのコマンド実行にもつながるとしています。対象は2023.8.13未満、2025.0〜2025.12.1未満、2026.0.1未満で、それぞれ2023.8.13、2025.12.1、2026.0.1で修正されています。現時点で悪用の報告は確認できていません。 出典：CVE記録 https://www.cve.org/CVERecord?id=CVE-2026-115731 出典：CVE記録 https://www.cve.org/CVERecord?id=CVE-2026-115732 出典：Perforce https://portal.perforce.com/s/cve/a91Qi000003IaHpIAK/report-deserialization-code-execution ⑦ Docker「Docker Desktop for Windows（WSL2利用時）」：権限のないコンテナから、Windows側のサービスやファイルに届いてしまう脆弱性（CVE-2026-112917、CVSS v4.0 9.2） WSL2を使う構成のDocker Desktop for Windowsで、権限のないLinuxコンテナが32ビットのシステムコールを使うことで、既定のセキュリティ制限（seccomp）をすり抜けられる問題です。その結果、ホスト向けのサービスや、ログイン中の利用者がアクセスできるWindowsのファイルにコンテナから届いてしまうおそれがあります。対象はx86-64のWSL2で、完全に修正されるのはDocker Desktop 4.98.0以降とWSL 3.0.3以降を両方そろえた場合で、Docker Desktopだけ更新してWSLが古いままだと影響が残るとしています。現時点で悪用の報告は確認できていませんが、外部のイメージを動かす開発用PCでは両方の更新を確認してください。 出典：CVE記録 https://www.cve.org/CVERecord?id=CVE-2026-112917 出典：Docker https://docs.docker.com/desktop/release-notes/#4980 ⑧ NetApp「StorageGRID（オブジェクトストレージ）」：内部ネットワークの特定ポートから不正な要求を受け付けてしまう脆弱性（CVE-2026-22058、CVSS v4.0 9.1） NetAppのオブジェクトストレージStorageGRIDで、製品固有の知識を持ち、ノード間通信用の「Grid Network」の特定ポートに通信できる攻撃者が、認証なしで不正な要求を送れてしまう脆弱性が公表されました。対象は11.3以降で、修正版は11.9.0.15、12.0.0.9、12.1.0.1です。攻撃にはGrid Networkへ届くことが条件のため、まずはこのネットワークが外部や一般の社内ネットワークから切り離されているかを確認してください。現時点で悪用の報告は確認できていません。 出典：CVE記録 https://www.cve.org/CVERecord?id=CVE-2026-22058 出典：NetApp https://security.netapp.com/advisory/NTAP-20261103-0001 ⑨ FreeRDP「FreeRDP（オープンソースのリモートデスクトップクライアント）」：サーバー証明書の確認が甘く、RDP通信を盗聴・改ざんされうる脆弱性（CVE-2026-121392、CVSS v4.0 9.1／v3.1 7.4） LinuxなどでWindowsにリモートデスクトップ接続するときに使われるFreeRDPで、TLS証明書の確認処理が、別名の欄（SAN）が一致しなくても古い方式の名前（CN）で通してしまったり、IPアドレスとホスト名を混同して照合したりする問題です。利用者の端末が信頼する認証局の証明書を持つ攻撃者が通信の間に入ると、接続先の確認をすり抜け、キー入力やクリップボード、画面の内容を盗み見られるおそれがあります。対象は3.32.2より前で、3.32.2で修正されています。現時点で悪用の報告は確認できていません。 出典：CVE記録 https://www.cve.org/CVERecord?id=CVE-2026-121392 出典：FreeRDP（GitHub） https://github.com/FreeRDP/FreeRDP/security/advisories/GHSA-jq25-3374-4262 ■注意点 ・米CISAのKEVへの追加は、10月30日のIvanti Connect Secure 2件以来で、今回は①のWordPress本体1件のみです。 ・Firefoxも159.0.1でレイアウト処理の境界条件の不備（CVE-2026-120572、CISAによる評価CVSS 8.8）を修正しています。Amazon RedshiftのJDBCドライバーでも、接続URLを操作できる場合にコードを実行されうる問題（CVE-2026-119084、CVSS v4.0 9.2）が2.3.0で修正されました。 ・国内では3日が祝日だったため、休み明けの4日にJVN・JPCERT/CCから注意喚起がまとめて出る可能性があります。 #脆弱性 #CVE #サイバーセキュリティ