🔥 CyberForge CVE of the Day #081 🚨 CVE-2026-106931 — SiteGuard Server Edition: preserve the evidence before repairing the statistics feature A web application firewall helps protect a server. Its own statistics processing must also respect the host's privilege boundary. EG Secure Solutions and JVN confirm exploitation of an OS command injection vulnerability in SiteGuard Server Edition. The documented consequence is potential execution of operating-system commands as root or SYSTEM on the affected server. The first defender action deserves attention: the vendor warns that updating or patching can erase attack traces. Download and preserve diagnostic information before the change where feasible, then apply the correct platform's repair. 🎯 THE QUICK HIT What happened: statistics processing contains CWE-78, OS command injection. Statistics is enabled by default; the public notices do not disclose a complete trigger sequence. Who should check: SiteGuard Server Edition owners on Apache httpd, Nginx or IIS, including the separate FreeBSD branches. Match platform/build and historical statistics state; preserve the IIS exception. Prerequisites matter: published vectors say local access, low privileges and no user interaction. The reviewed sources do not establish an unauthenticated Internet endpoint. A WAF's deployment inside a web server does not establish that route. Start with: owner, active build/feature state, then diagnostic download BEFORE update or patch where feasible. Urgent containment can take precedence; record resulting collection gaps. Follow: installation/feature history → diagnostics → host/process evidence → identity/change context → verified serving repair. Escalate unexplained privileged activity with corroboration. Vulnerability presence requires remediation; suspicious activity also needs investigation. Keep the source conflict: official notices confirm exploitation. No KEV match and CISA's dated SSVC “none” do not cancel that confirmation. 🔑 KEY DETAILS • Product: EG Secure Solutions Inc. SiteGuard Server Edition, a host-based WAF integrated with a web server. • Affected component: statistics processing, enabled by default. • Weakness: CWE-78, improper neutralisation of special elements used in an OS command. • JPCERT CNA / JVN assessment: CVSS v4.0 8.5 High. • Exact v4.0 vector: CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N • Additional published assessment: CVSS v3.0 7.8 High. • Exact v3.0 vector: CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H • NVD status: Deferred. Its v4.0 and v3.0 metrics are Secondary, attributed to JPCERT; no separate NIST assessment is present in the returned record. • JVN's headline says Critical and the vendor labels its notice urgent. Those advisory labels do not change the published High CVSS scores or their versions. • Vector prerequisites: local, low privileges, low complexity, no user interaction. v4.0 AT:N does not remove feature/access conditions. • Potential impact: OS commands with root or SYSTEM privileges on the server running the affected product. A particular site's compromise, persistence or data theft is not established by that capability statement. • Fix: Ver8.00 Update 5 for Apache httpd, Nginx and IIS outside FreeBSD; Ver7.00 Update 6 for Apache httpd/Nginx on FreeBSD. • Alternative: the vendor provides a statistics-processing file-replacement patch, including for end-of-life versions. Obtain the package and verification instructions matched to the installation. • Temporary workaround: JPCERT/CC says disabling statistics avoids the vulnerability's effect. Use the vendor's supported procedure; do not treat a workaround as evidence of historical safety. Exploitation and prioritisation: The 14th October vendor/JVN notices confirm exploitation; JPCERT-AT-2026-0032 recommends considering compromise investigation. The notices do not publish a victim count, initial attack date or actor. CISA KEV: no exact CVE match in catalogue 2026.10.16, released 16th October at 17:15:48.8752 UTC, retrieved 19th October. The official feed and official GitHub mirror agree. This is a dated catalogue lookup, not evidence that no attacks occurred. No KEV-specific deadline is assigned here. CISA ADP SSVC 2.0.3: exploitation none / automatable no / technical impact total, assessed 16th October at 15:15:38.574629 UTC. That conflicts with the official exploitation statements; it does not overrule them or establish that the threat has ended. FIRST EPSS: 0.006620000 = 0.662% predicted exploitation probability over the next 30 days; percentile 0.506620000 = 50.662nd percentile, score date 18th October. The rank is not a second probability, and neither value estimates whether your host was already compromised. 🧬 WHAT ACTUALLY WENT WRONG? The documented boundary is between statistics processing and privileged OS command execution. CWE-78 identifies insufficient neutralisation when data enters an OS command. It does not identify this case's exact input field, command, schedule, file path or transport. The supported sequence is short: applicable installation with statistics enabled → access modelled as local with low privileges → command injection in statistics processing → possible root/SYSTEM execution. Official sources confirm exploitation without publishing the complete incident sequence. Forge interpretation: investigate the processing context and any earlier access that made exploitation possible. An existing foothold is a timeline question, not a proven first stage or a reason to invent a second CVE. Diagnostic download is a preservation route; it does not identify the vulnerable endpoint. A web-server deployment does not establish an unauthenticated Internet exploit. 📦 WHICH DEPLOYMENTS BELONG IN SCOPE? Statistics must be enabled; its default is enabled. The lower affected boundary is Ver2.20. Apache httpd/Nginx outside FreeBSD: Ver2.20 to before Ver8.00 Update 5; named fix Ver8.00 Update 5. IIS: the same upper boundary, but Ver3.10 through Ver4.00 Update 4 are NOT affected by this CVE. The affected range resumes at Ver4.00 Update 5 and ends before Ver8.00 Update 5. Do not flatten this into every IIS version below 8. Apache httpd/Nginx on FreeBSD: Ver2.20 to before Ver7.00 Update 6; named fix Ver7.00 Update 6. Retain complete product labels and Update numbers. The CNA encodes ranges and IIS status changes; use the readable vendor matrix rather than a shortened numeric comparison. Inventory each serving installation and any older copy capable of returning to service. Record host, platform, edition/build, owner and time. Check replicas/recovery images where they exist. A fixed build or disabled setting today does not establish the historical state; reconstruct configuration and repair times where records permit. 🕰️ EXPOSURE WINDOW AND TIMELINE 29th September: the vendor says direct-support customers were notified of the issue and countermeasures. This is neither a first-exploitation date nor proof that customers installed a repair. 14th October: public vendor/JVN/JPCERT notices, confirmed exploitation and remedies. CNA publication: 04:45:07 UTC; NVD publication: 05:16:42 UTC. 16th October: dated CISA SSVC and retrieved KEV catalogue. 18 October: returned EPSS score. 19th October: this review. Set the local hunt window from the earliest supported affected installation, enabled statistics and relevant access through verified correction/workaround. Disclosure is not the start of every exposure. Record uncertainty and preserve older evidence where retention allows. 🧭 SOC INVESTIGATION TRAIL Objective: investigate unexplained privileged activity on applicable hosts while proving repair coverage separately. These are Forge defensive hypotheses, not vendor-published signatures. Agree assets, UTC bounds, read access and collection health first. C01 — ESTABLISH APPLICABILITY Action/location: confirm full SiteGuard edition/build and historical statistics state through the supported management view, inventory and change history. Internal configuration paths are not disclosed by the notices. Signal/correlation: match the affected platform and release with enabled statistics on the same serving host and dates. Retain the IIS exclusion and separate FreeBSD branch. Benign causes/limits: stale inventory, an inactive installation or a correctly matched patch can explain a version hit. A ticket alone does not prove patch application. Current feature state does not prove historical state. Escalate unresolved exposure to service/vulnerability owners; additional suspicious evidence is needed to classify an incident. C02 — PRESERVE BEFORE REPAIR Action/location: use the authorised web administration route to download diagnostic information before update or patch where feasible. Signal/correlation: keep the original export, host/build, acquisition time, collector and hash; match them to the change record and retained host/external evidence. Work on protected copies. Limits: a readable export proves a collection exists, not that it contains every required event. The complete diagnostic schema is not disclosed. A post-repair export may have lost earlier traces. Escalate failed, corrupt, late or incomplete acquisition as a collection gap. Urgent containment may precede ideal preservation; record the reason and loss. C03 — HUNT HOST/PROCESS EVIDENCE Action/location: review existing EDR, process audit and relevant system records in the agreed window. Establish the actual statistics-processing identity and executable context with the owner/vendor; do not guess a service name. Signal/correlation: unusual privileged execution or file changes become leads when ancestry, account and time connect them to that context. Windows 4688 or Sysmon process creation helps only if enabled and retained. Unix system logs are not complete process histories. Benign causes/limits: patching, diagnostics and approved maintenance can produce privileged actions. Missing process data is a gap, not a negative result. Escalate unexplained correlated activity with native records and coverage limits; a generic interpreter name is not a CVE-specific IOC. C04 — CORRELATE IDENTITY AND CHANGE Action/location: join candidate host events to retained authentication, remote administration, network and change records in existing SIEM/EDR/source systems. Confirm each schema and permission boundary. Signal/correlation: use host identity, UTC time, account and available process/session identifiers. Unexplained privileged activity outside an approved change deserves review. PIDs can be reused; clock skew and ingestion delay can distort order. Benign causes/limits: support sessions, automation and shared accounts require owner/ticket checks. A proxy-observed address is not automatically the originating actor. Escalate credible unauthorised outcomes to incident response with supporting records and alternatives. One ambiguous event remains suspicious, not proven compromise. C05 — CHECK PRIVILEGED EFFECTS Action/location: where suspicion exists, review authorised evidence of changes or access within the server's real authority: application content, configuration, relevant credentials and connected resources. Do not collect secrets merely to fill a checklist. Signal/correlation: link unauthorised changes or subsequent account use to host/process evidence, times and maintenance. Root/SYSTEM capability justifies these questions; it does not prove theft, persistence or lateral movement. Benign causes/limits: deployments and legitimate administration can explain changes; expired retention can hide context. Escalate corroborated findings for scoped containment, recovery and credential decisions. Avoid automatic rebuild/rotation from a version hit; do not close an evidenced incident solely because the vulnerable code was patched. C06 — VERIFY THE CORRECTION Action/location: obtain vendor-approved proof of the fixed running build or installation-matched replacement patch. The public alert supplies no universal verification command, patch-file hashes or activation promise. Signal/correlation: connect acceptance evidence to each active host, complete build/platform, change time and required activation steps. Check service health and intended protection. For disabled statistics, record the effective setting and a repair plan. Benign causes/limits: stale inventory, copied installers, incomplete rollout and restored images may mislead. Downloading a fix is not completion; every relevant serving copy needs verification. Escalate old instances, missing patch proof, continuing anomalies or important gaps to an accountable owner. Repair coverage and historical compromise remain separate conclusions. ANALYST HANDOVER Record asset/owner → platform/build and feature history → UTC window and basis → evidence/record IDs → check, cap and result → confidence/gaps → repair proof → next owner/time. Classify exposure established, suspicious indicator, validated compromise or telemetry unavailable/insufficient. “No matches” needs defined assets, interval, source health and query limits. No findings are not proof of a clean system. 🔎 INDICATORS AND OBSERVABLE BEHAVIOUR No CVE-specific IP/domain/hash/detection-rule set or working public reproduction was verified in this bounded primary-source review. That does not contradict confirmed exploitation. The host/process checks are Forge behavioural leads, not CVE signatures. Generic interpreter or directory names are not IOCs. Correlate each lead and test legitimate explanations. Ask the vendor for supported triage; do not invent a payload, endpoint or log path to compensate for undisclosed mechanics. 🧰 TOOLS AND BOUNDED CHECKS — PLAIN LANGUAGE A — PRODUCT ADMINISTRATION With authorised access, confirm host/build and statistics state, then obtain the vendor-described pre-change diagnostic download. Record source, acquisition time and readability in approved storage. This establishes inventory and available evidence, not complete telemetry or absence of exploitation. Protect potentially sensitive exports; the service owner and incident lead own the handoff. B — EXISTING EVENT VIEWER, EDR OR SIEM Scope hosts and UTC interval before reading retained events. For applicable Windows hosts, event 4688 needs process auditing; command-line detail requires separate configuration. Sysmon event 1 is useful only where already collected. Review named fields/event versions; correlate ancestry, identity and maintenance. Record result caps, denied access, missing fields and retention gaps. Split dense windows or use approved full collection instead of treating the first page as complete. Other host platforms need their existing audit/EDR schema. These checks were documentation-reviewed, not run on a SiteGuard host. C — APPROVED EVIDENCE/HASHING TOOLS Hash preserved originals and working copies with the team's established tools. Record algorithm, object size, acquisition method/time and collector. A matching digest supports copy consistency, not authenticity, malware status or export completeness. Keep native formats in approved storage; do not upload client evidence to public services. Reads can consume resources and leave audit traces. The case owner must connect results to the investigation question. 🩹 REMEDIATION AND VERIFICATION 1 — Confirm full platform/build and statistics history, retaining the IIS exclusion. Follow incident procedures for active harm; catalogue absence does not cancel confirmed exploitation. 2 — Preserve diagnostic information before update or file-replacement patch where feasible. Retain relevant existing host/external records too; document collection gaps and containment trade-offs. 3 — Apply Ver8.00 Update 5 for non-FreeBSD Apache/Nginx/IIS, or Ver7.00 Update 6 for FreeBSD Apache/Nginx. Alternatively obtain the vendor's installation-matched statistics patch. An EOL patch does not restore general support. 4 — Verify the serving state and health on each relevant host. Ask the vendor for replacement-patch proof rather than assuming the product version alone covers that route; a file replacement need not imply a changed overall version label. Follow required activation instructions without inventing a restart-free or reboot requirement. 5 — Investigate earlier access separately. Evidence of privileged compromise may require further containment, recovery or credential work. A fixed build does not establish eradication. Temporary control: JPCERT/CC says disabling statistics avoids this vulnerability's effect. Use the vendor's procedure, verify the effective state, record lost statistics functionality and plan a supported repair. It does not clear earlier activity. Completion requires accountable repair/control proof and a bounded investigation conclusion, with remaining gaps visible. 🧾 EVIDENCE SEPARATION Official: statistics-feature command injection; local/low-privilege vectors; potential root/SYSTEM execution; platform fixes/IIS exclusion; pre-change preservation; confirmed exploitation. Conflict: CISA's dated SSVC “none” disagrees with the advisories. NVD Deferred is a record status; urgent/Critical headlines are distinct from High CVSS ratings. Forge analysis: preserve diagnostics and correlate existing host, identity and change evidence. These methods are not observed victim findings. Unknown: complete trigger/input/endpoint, preliminary access path, process/file names, patch-file hashes, diagnostic schema, actor, victim count and a reproduction verified here. 🔥 CYBERFORGE VERDICT Applicable SiteGuard Server Edition hosts deserve prompt attention: official sources confirm exploitation and the potential outcome reaches root/SYSTEM. Confirm the real branch and statistics state, preserve diagnostics before repair removes traces, then verify the correct correction is serving. Keep historical compromise tied to evidence; a completed patch is not an incident conclusion. 💜 Preserve the trail, repair the right branch, and verify the state in service. 🔗 SOURCES AND FURTHER READING Vendor alert, affected/fixed versions and pre-change preservation: eg-secure.co.jp/siteguard/ne… JVN#88474777, English: jvn.jp/en/jp/JVN88474777/ JPCERT-AT-2026-0032, workaround and investigation context: jpcert.or.jp/at/2026/at26003… CVE record / authoritative machine-readable record: cve.org/CVERecord?id=CVE-202… cveawg.mitre.org/api/cve/CVE… NVD attribution/status: nvd.nist.gov/vuln/detail/CVE… CISA KEV catalogue used for the dated lookup: cisa.gov/sites/default/files… FIRST EPSS response: api.first.org/data/v1/epss?c… Windows event collection / 4688 prerequisites and schema / Sysmon: learn.microsoft.com/en-us/po… learn.microsoft.com/en-us/pr… learn.microsoft.com/en-us/sy… #CyberSecurity #CVE #SiteGuard #BlueTeam #ThreatHunting #IncidentResponse #SOC #CyberForge

🔥 CyberForge CVE of the Day #077 🚨 CVE-2026-104935 — Ivanti Connect Secure: unauthenticated command execution at the VPN edge Your VPN gateway can still be serving users while an earlier intrusion remains unresolved. Ivanti confirms exploitation of this Connect Secure flaw affecting a limited number of customers, and CISA has added the exact CVE to KEV. Ivanti CNA rates it CVSS v3.1 8.6 High. Urgency also comes from confirmed exploitation, exposure and the appliance's trusted connections. Repair the applicable branch and platform, preserve independent evidence and follow the trail into authentication and directory records. ⚠️ A clean Integrity Checker Tool (ICT) result cannot clear the memory-only activity described in the original field research. Root access in that case required a separate escalation; keep the entry CVE and the wider chain distinct. 🗓️ Case status checked: 14 October 2026, 09:06:03 UTC / 10:06:03 BST. This is a source review and defender guide; no appliance was tested here. 🎯 THE QUICK HIT What happened: Ivanti identifies authentication bypass by spoofing, allowing a remote unauthenticated attacker to execute arbitrary commands on affected Connect Secure appliances. The reported entry began in the cgi-server service context. Who should check: owners of affected 22.8 and 25.1 deployments. Record the actual running branch, build, physical or virtual model, reachable VPN address and active/standby roles before selecting a repair. An upgrade target must fit the platform. Where the fixes land: the vendor names 25.1.1.2, 22.8R2.5 and the compatible 25.1.3.0 / 25.1.3.1 path. These are branch/platform choices, not interchangeable instructions. Keep the current migration guide beside the advisory. Why urgent: confirmed exploitation, KEV and CISA's active assessment. Missing EPSS is not zero risk; scoring does not replace local exposure and incident decisions. Why difficult: reported memory-only changes, restored configuration and selected log removal. Healthy service or quiet logs can leave an evidence gap. Follow the trust: compare gateway activity with appliance-associated accounts, authentication, directory access and later credential use. The reported LDAP, LAPS and BitLocker outcomes belong to one observed chain, not every affected installation. Track entry-path repair and earlier appliance/identity integrity separately, each with evidence, owner and confidence. 🔑 KEY DETAILS • CVE: CVE-2026-104935; product: Ivanti Connect Secure (ICS). • Weakness: CWE-290 — Authentication Bypass by Spoofing. • Ivanti CNA: High, CVSS v3.1 8.6. • CNA vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:L. • Network reachable, low complexity, no prior privileges and no victim interaction in that assessment. • Rendered Ivanti advisory: also 8.6 High, but prints CVSS v3.0 and CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:L. Retain that source/version difference. • NVD: Analyzed; its v3.1 metric is Secondary and attributed to Ivanti's CNA. No independent NIST score or published v4.0 score was present. • Vendor exploitation statement: limited customer exploitation confirmed at disclosure. • KEV: exact CVE listed in catalogue 2026.10.13, containing 1,741 entries. Added 13 October; recorded due date 16 October 2026. • KEV ransomware campaign use: Unknown. Forensic triage: Yes. Neither field certifies a particular customer's incident status. • CISA ADP/SSVC 2.0.3: Exploitation active, Automatable yes, Technical Impact total. This is CISA's assessment, separate from CVSS and local findings. • FIRST EPSS: HTTP 200/OK, total 0, empty data. Probability, percentile and score date unavailable, not zero. • Original research: Volexity's 13 October field report; activity reconstructed from 3 October, investigation beginning 5 October. • Published indicators reviewed: one exploitation IP and two YARA rules with different purposes. No public exploit was executed in this review. 🧠 THE FAILURE IN PLAIN TERMS Public request handling and protected work should agree about what an unauthenticated visitor may reach. In the reported entry, those decisions diverged: a request admitted through public handling reached protected processing, resulting in command execution. That establishes an intrusion point, not universal root access or compromise of every connected account. Volexity describes an additional escalation involving a separate appliance component before root access. At the research's 13 October publication, a fix for that separate issue was being prepared. This bounded review did not establish its current independent identifier or repair status. Do not present yesterday's statement as proof that every part of the chain remains unpatched today. Runtime changes, restored configuration and selected log removal made familiar checks less decisive. No first-stage webshell or backdoor was identified in the reported case; its absence is not a clearance condition for this pattern. Commands and returned results were carried in the exploitation HTTPS traffic in the reported case. A hunt that requires a separate command-and-control domain could miss that evidence. Begin with available request, connection, appliance and identity records, with the limits of each made explicit. 📦 THE VERSION AND PLATFORM CHECK Keep the vendor's branch matrix intact: 25.1.1 branch: 25.1.1.1 and prior are directed to 25.1.1.2, released 5 October. The advisory names physical ISA6000/ISA8000 and virtual ISA4000/ISA6000/ISA8000 for that path. 25.1.2 branch: 25.1.2.2 and prior are directed toward the compatible 25.1.3.0 / 25.1.3.1 route. Confirm the source model, current version and supported method rather than treating that destination as an automatic in-place upgrade. 22.8 branch: 22.8R2.4 and prior are directed to 22.8R2.5, released 12 October, when immediate compatible migration is not possible. Ivanti prefers migration to a compatible 25.1.1.2 or later release. Treat 22.8 as a bridge with a migration owner. Vendor exclusions for this CVE: 22.7R2.14 and prior, and 25.1.3.0 and later. An exclusion for this identifier does not certify an older appliance against other vulnerabilities or historical intrusion. The 25.1.3 family uses ISA4500/ISA6500/ISA8500 platforms. Existing ISA6000/ISA8000 appliances and existing virtual deployments cannot simply be assumed to support a direct 25.1.3.0 upgrade; migration or a new deployment can be required. The migration guide limits direct upgrades to supported hardware/source combinations and requires vTPM for virtual deployments. Clusters need their own plan. Direct 22.8R2-to-25.x cluster upgrades are not supported in the reviewed guide; use Ivanti's individual upgrade and cluster recreation procedure where applicable. Include active, standby and any independently serving node in the repair evidence. The guide has duplicated table headings; confirm the exact supported route rather than infer a universal upgrade promise. There is also a source gap: the CNA's custom-version record defaults to affected and explicitly lists 25.1.3.0, 25.1.3.1, 22.8R2.5 and 22.7R2.14 as unaffected. It omits 25.1.1.2, although the rendered vendor advisory explicitly names that backport. Preserve both facts and use the vendor matrix for that repair decision. Do not sort these mixed release strings into a single “everything below 25.1.3.0” rule. The backport, excluded older branch and platform requirements make that shortcut misleading. Ivanti also states a 31 January 2027 end-of-life date for 22.7/22.8; lifecycle migration is a separate task from today's entry-path repair. 🛡️ THE SOC TRAIL — SIX CHECKS TO KEEP WITH THE IMAGE 01 — SCOPE: establish the actual exposure Work with the VPN owner to record every serving ICS node, running version, appliance model, deployment type, VIP, external route and relevant administrative path. Use inventory and supported appliance views; a banner, DNS name or planned upgrade ticket is supporting context, not complete build evidence. Compare inventory to the matrix, including standby/restored instances and old templates. Record each vulnerable node's exposure interval. Shared addresses, stale inventory and maintenance can explain discrepancies. Resolve node mapping. Escalate reachable affected deployments, unsupported repairs and unowned serving nodes. 02 — PRESERVE: keep independent evidence available Use supported Ivanti/IR collection for exports, logs, configuration history and available memory, disk or core evidence. Record collection time, node, timezone and gaps; keep restricted copies under the evidence process. Preserve independent gateway, firewall, load-balancer, authentication and directory records. They may survive appliance log deletion. Coordinate collection and urgent containment with the incident owner. A reboot or recovery can alter runtime evidence. Record approval, time and expected loss if it must proceed. A standard backup or disk-only export does not establish historical process memory. Maintenance, log rotation and normal retention can create gaps too. Correlate them with change history. Escalate lost or contradictory evidence, unexplained log removal and uncertainty about whether required memory evidence can be collected safely. 03 — HUNT: use indicators as leads with coverage limits Volexity's reviewed CSV lists 108.165.147.64 as an exploitation IP associated with its UTA0576 investigation. Search relevant retained connections and requests in a bounded time window, then map any hit to the appliance, route and surrounding activity. A match alone does not prove exploitation or current ownership. No match cannot clear other sources or retention gaps. Check local context before broad blocking. Review request anomalies, protected processing inconsistent with authentication, runtime changes and selected log removal. Use available fields and known administration; no universal event ID or query is established. Monitoring, administration and approved collection can look unusual. Correlate auth, changes, node and time. Escalate corroborated unauthorised effects or disagreements with independent evidence. 04 — CORRELATE: follow the gateway's trusted identity Identify ICS directory/authentication accounts. Join gateway activity to directory access and later account use by account, node, destination and UTC window. Preserve original timezone and clock-skew notes. Volexity reports attempts to access LDAP/domain credentials and directory information, including LAPS and BitLocker data, during its observed chain. Those are investigation prompts where the local permissions and telemetry support them; they are not claims that every affected appliance exposes those data. Compare account use with expected purpose, source and targets. Confirm permissions and available auditing. Broad directory searches can be authorised; new sources using appliance-associated credentials deserve context. Avoid causal shortcuts from one shared account or adjacent timestamp. Join multiple records, resolve NAT/proxy attribution and check approved work. Escalate corroborated credential misuse, unexpected privileged access or insufficient identity telemetry for a material lead. 05 — REMEDIATE: apply the supported repair and incident plan Select the exact branch/platform route with the appliance owner. Preserve needed evidence, address exposure and use current Ivanti upgrade or migration guidance. Record the target, supported path, maintenance window and each node's resulting running build. For suspected compromise, involve the incident owner in recovery and credential decisions. Identify potentially exposed accounts/secrets and coordinate containment, revocation or rotation with service owners and evidence. The advisory links a recovery procedure that led to an Ivanti login during this review. Its authenticated steps were not reviewed here. Obtain the current procedure through the vendor or authorised response team; do not substitute an invented reset, reimage or console sequence. A failed upgrade, incompatible model, affected standby or blocked collection needs an owner and escalation. Network restrictions were not validated here as a CVE fix. 06 — VERIFY: prove repair while keeping historical questions open Confirm active/standby running builds, supported platform and serving topology. Check that old affected deployments cannot resume service. Record vendor health/integrity results and time. Then review historical integrity separately. A successful upgrade and a clean ICT result do not reconstruct earlier memory activity, restore deleted records or invalidate corroborated credential-use evidence. Reconcile independent gateway and identity history with appliance findings. State sources, analyst, window and gaps. “No findings in these retained records” is bounded; “no compromise” needs sufficient evidence. Keep missing memory, expired logs, unexplained account use and separate escalation status visible. Escalate unresolved material evidence gaps or a suspicious chain that survives the repair. Close each task against its own evidence: exposure, entry repair, incident investigation, identity action and residual coverage. 🔎 IOC AND YARA — TWO DIFFERENT KINDS OF HELP The reviewed set contains one IP and two YARA rules. Record source/date with any search; this small set does not cover all infrastructure or behaviours. The rule exploit_log_ivanti_rce matches a published request-context string in file or memory evidence. A match is a contextual lead, not proof that a command succeeded or that the gateway was compromised. The rule exploit_py_ivanti_oct26 is described by the researcher for memory and relates to implementation markers from the separate escalation. Its presence should be investigated in the appropriate evidence context; it must not be reported as proof that the entry CVE alone grants root. Respect evidence type, YARA compatibility, permissions and timeouts. Errors or incomplete scans are not negatives. A clean scan cannot exclude changed strings/tooling or uncaptured evidence. Our local YARA 4.5.8 check compiled the original rules and passed three benign text controls: a negative control and one literal signature control for each rule. That proves basic syntax and matching on those controls only. No appliance, actual malware, memory image or live detection effectiveness was tested. The rules' Critical metadata does not change Ivanti CNA's High 8.6 score or establish a local incident severity. 🧰 TOOLS THAT CAN HELP THE DEFENDER Ivanti appliance views and migration guidance: establish branch, model, topology and repair compatibility. Confirm running builds; downloads and ticket status alone cannot prove repair. Ivanti ICT: run and review it as directed by the vendor. Retain its result as evidence, while keeping the researched memory-only and log-removal limitations alongside it. It contributes to an investigation; it cannot independently clear this reported pattern. SIEM and network records: search retained VPN, load-balancer, firewall and connection history using mapped appliance addresses and UTC windows. Note whether the source actually includes requests, headers, bodies or only connections; HTTPS traffic does not automatically expose its contents to every sensor. Directory auditing: examine appliance accounts, permissions and later use against authorised baselines. State sources and retention; a query cannot recover auditing that never existed. YARA on authorised evidence copies: use the original licensed rules with compatible tooling in a bounded offline analysis workflow. Record source hashes, target evidence, rule version, completion and hits. Keep sensitive evidence and results within the case's access controls. IR tools: choose supported collection with the appliance specialist. Do not assume a general endpoint agent can be installed on the gateway or a shell action is harmless. This public edition uses plain-language checks, without request recipes or escalation commands. 📆 WHAT THE DATES ACTUALLY SAY Volexity reconstructed activity from 3 October and began the investigation on 5 October. Its reported appliance was 22.8R2.4 build 19097 and had been patched/current at that investigation time. That historical description is not a claim that 22.8R2.4 is current or repaired now. Ivanti says part of the issue was discovered and fixed in the July 25.1.3.0 release, while backports were being prepared when exploitation occurred. The advisory names the 25.1.1.2 release on 5 October and 22.8R2.5 on 12 October. No exact July release day was established here. The CVE record and public advisory were published on 13 October, as was the reviewed Volexity report. KEV addition is also 13 October, with the entry recording 16 October as its due date. The feed's action text references BOD 26-04 and forensic triage requirements; organisations must check their applicable obligations. The recorded date is not presented here as a universal deadline for every reader. Source cutoffs matter. Today's review ends at 09:06:03 UTC on 14 October. Later vendor updates, additional indicators or a separate escalation advisory need a fresh check, not an assumption based on this snapshot. 📋 A USEFUL HANDOVER Hand over the node map, branch/model evidence, exposure interval, repair path and active/standby results, with the vendor source for the 25.1.1.2 gap and migration limits. For each lead, record event source, account, connection/request context, UTC window, corroboration and approved work checked. Distinguish an actual artifact match from a local control and a researched capability from an observed effect. Give memory/log/audit gaps, node uncertainty and inaccessible recovery detail an owner and consequence. Track recovery, credentials and separate escalation review individually. The image's six boxes start empty for the reader's work. Each tick should point to case evidence; our editorial checks do not complete anyone's investigation. 💜 THE CYBERFORGE VERDICT Prioritise affected ICS now: exploitation is confirmed and KEV-listed. Match branch/platform/topology, then verify every serving node's running build. Keep the investigation alive alongside the repair. The reported chain shows why a clean ICT result, restored configuration or quiet local logs can leave substantial uncertainty. Independent network and identity evidence may be essential to resolve it. Keep the boundaries precise: High 8.6 remains the CNA score; 25.1.1.2 is a vendor-backed backport despite the structured-record omission; root and directory outcomes came from a wider reported chain. None of those distinctions reduces the urgency of a reachable affected gateway. 🧾 PRIMARY SOURCES AND FOLLOW-UP Ivanti advisory and branch fixes: hub.ivanti.com/s/article/Sec… Ivanti platform/cluster migration guidance: hub.ivanti.com/s/article/Iva… CVE Program record: cve.org/CVERecord?id=CVE-202… NVD record: nvd.nist.gov/vuln/detail/CVE… Volexity's original field investigation: volexity.com/blog/2026/10/13… Original indicators and YARA: github.com/volexity/threat-i… CISA KEV: cisa.gov/known-exploited-vul… FIRST EPSS: first.org/epss/ 🛡️ Repair the entry. Preserve the trail. Verify the identity story. #CyberForge #CVEOfTheDay #CVE2026104935 #Ivanti #ConnectSecure #SOC #BlueTeam #IncidentResponse