Workforce Development for Modern Networking and Cybersecurity Teams
Develop and refine skills for improved organizational resiliency with hands-on training and certifications.
INE offers a continuous
learn by doing training model
Award winning, hands-on and technically challenging training ensures learners have the in-depth knowledge and skill set to master the subject.
Build a Team Training RoadmapPopular Learning Paths & Courses
Made for Organizations
Our full-cycle training methodology was created with organizations in mind. INE provides organizations with what they need to develop, upskill, and retain employees in and across cybersecurity and networking roles.
Enterprise and Business SolutionsIntersection of Cybersecurity and Networking
Develop skills with immersive, scenario-based practice labs.
INE understands that teaching “how to” under "ideal" conditions stops short of being work-role ready. We place great emphasis on creating scenarios which are as close to real world circumstances as possible to help create a resilient team.
Top News
The Request Died but Its Ghost Lived On: Inside PHP’s CVE-2026-109619
Imagine you are running a standard PHP application behind Apache. It serves pages, handles file uploads, tracks session state. Nothing exotic. One afternoon, two HTTP requests arrive at your server a few hundred milliseconds apart. The first one is a multipart upload that is deliberately too large. It crashes against the memory limit, and PHP tears it down. The second is another multipart upload that looks almost identical. It lands on the same Apache worker. By the time it finishes, someone who never authenticated, never exploited any application-level bug, and never touched your code is running shell commands as your web server user.That is CVE-2026-109619, and it targets something most PHP administrators never think about: what happens to worker-global state when a request dies mid-initialization. This post walks through the vulnerability, why it exists in PHP’s architecture, and how a pair of unauthenticated HTTP requests turns into remote code execution. The interesting part is that this is not an application bug. It is a lifetime management failure in the PHP runtime itself, hiding in the gap between session initialization and request initialization.Vulnerability Overview
CVECVE-2026-109619. Its sibling, CVE-2026-109618, is a separate bug fixed alongside it and is not covered here.Affected runtimePHP, the server-side scripting engine, when running as an Apache module (mod_php / apache2handler) with the prefork MPMAffected versionsPHP across multiple branches: 8.4.x before 8.4.27, 8.3.x before 8.3.36, 8.2.x before 8.2.35, and 8.5.x before 8.5.12. Source-only backports exist for 7.4, 8.0, and 8.1. The lab targets PHP 8.4.26.TypeUse-after-free in worker-global session state, leading to unauthenticated remote code execution.SeverityCVSS v4.0 score of 9.2 Critical, assigned by the PHP project.Attack VectorIn the demonstrated exploit chain, two sequential HTTP multipart requests to any PHP endpoint on a prefork Apache worker with session.upload_progress.enabled set to its default of On. The advisory describes additional stale-state paths beyond session upload progress.Exploitation in the WildEarly exploitation attempts were detected by Cloudflare WAF telemetry and independently reproduced by watchTowr. Multiple public proof-of-concept scripts exist, though few work reliably against default configurations due to ASLR on x86-64. The vulnerability has been dubbed “PHP2Shell” alongside its sibling, CVE-2026-109618.Confirmed impactUnauthenticated RCE over HTTP, demonstrated against Apache with mod_php on default settings, before any application code runs.Skill Dive CVE PHP2Shell: Exploiting Stale Global State
The Setup: How Apache Keeps PHP AliveTo understand this bug, you need to understand one architectural decision that makes it possible. Apache’s prefork MPM spawns a pool of child processes. Each child handles one request at a time, sequentially. When PHP runs as mod_php (reported by PHP as the apache2handler SAPI), the PHP interpreter lives inside that Apache child process. It is not started fresh for each request. It persists.That persistence is the key. Between requests, the PHP runtime resets most of its state: it tears down the request heap, destroys variables, and reinitializes for the next request through a phase called RINIT (Request INITialization). But some state is deliberately kept across requests at the worker-global level, managed through module globals rather than per-request allocations.PHP’s session extension maintains one such piece of worker-global state: PS(http_session_vars). The PS() macro, defined in ext/session/php_session.h, accesses the session module’s global structure. PS(http_session_vars) is a pointer that, during a request, references the session data stored in the request’s own memory. Between requests, it is supposed to be reset to NULL so the next request starts clean.Now add one more feature to the picture: session upload progress. When session.upload_progress.enabled is On (which it is by default), PHP hooks into Apache’s multipart parsing very early, before RINIT even runs, to start tracking upload progress in the session. This early initialization is the crack in the wall.The entire vulnerability lives in the gap between “session state was initialized early” and “request state was cleaned up normally.” When something goes wrong in that gap, PS(http_session_vars) can be left pointing at memory that no longer belongs to the current request, or to any request at all.Act One: The Same-Request Sibling (CVE-2026-109618)CVE-2026-109619 is not PHP’s first encounter with this particular class of lifetime error. Its sibling, CVE-2026-109618, describes a related vulnerability in the same session-initialization code, but with a crucial difference: the trigger and the effect both happen within a single request.In CVE-2026-109618, the failure mode is a partially initialized cleanup path. A single request can reach a state where the session module’s initialization started (because of upload progress) but did not complete normally, and the cleanup path during that same request’s teardown does not properly account for the partial state. The result is a use-after-free, but it is scoped to the lifetime of one request.The fix for CVE-2026-109618 addressed the same-request cleanup path. But the deeper architectural issue, that PS(http_session_vars) is a worker-global pointer that can reference request-scoped memory, was not fully resolved. The pointer could still escape the request boundary.Act Two: The State That Crossed the BoundaryNow think about what happens when the failure is not contained within a single request.Request A arrives as a multipart upload. Because session.upload_progress.enabled is on, PHP’s session module hooks into the multipart parser early and begins session initialization before RINIT runs. During this early phase, PS(http_session_vars) is set to point into the request’s memory. Then the upload’s deliberately oversized field hits the configured memory limit, and PHP bails out with a fatal error.Here is where the lifetime violation occurs. During this abnormal shutdown, the session module’s reset logic is skipped. The request heap is freed, variables are torn down, the request is gone. But PS(http_session_vars) still holds its old value. It is a worker-global pointer, and it now points to freed memory from a dead request.The Apache child process does not exit. It is a prefork worker. It goes back to the connection pool and waits for the next request.Request B arrives. It is also a multipart upload, carefully constructed. When PHP begins processing it, the new request gets a fresh heap. The attacker’s controlled multipart data is allocated into this heap. With the right sizes and contents, this new data occupies the exact memory that the dead Request A’s session data used to occupy. The stale PS(http_session_vars) pointer now points to attacker-controlled data.When session initialization runs for Request B, it consumes PS(http_session_vars) before replacing it. It interprets the attacker’s data as a HashTable, PHP’s internal dictionary structure. The attacker has crafted this fake HashTable so that its destructor function pointer field points to zif_system, the C-level implementation of PHP’s system() function. When PHP’s cleanup code calls the destructor, it executes zif_system with attacker-controlled arguments.The result is arbitrary command execution as the web server user, typically www-data.How It Actually Works: The Producer/Consumer ChainLet us walk through the two requests in detail, because the exploit is a precisely sequenced two-phase operation.Phase 1: The ProducerThe producer request is a multipart POST to any PHP endpoint. Its job is to corrupt the worker’s global state and then die. The request carries:A PHP_SESSION_UPLOAD_PROGRESS field in the multipart body. This triggers the session upload progress handler, which runs before RINIT and initializes session state early, setting PS(http_session_vars) to point into the request’s memory.An oversized field that, when PHP tries to process it, pushes memory usage past the configured limit (in the lab, 8 MB). PHP raises a fatal error and begins abnormal shutdown.During this abnormal shutdown, the session module’s cleanup does not execute its full reset sequence. Specifically, it does not set PS(http_session_vars) back to NULL. The request heap is freed, but the pointer remains.The worker is now poisoned. It returns to the connection pool carrying a dangling pointer in PS(http_session_vars).Phase 2: The ConsumerThe consumer request targets the same worker. It is also a multipart POST, but its purpose is different: it fills the new request’s heap with controlled data that lands at the address the stale pointer references.This is a standard heap-spray technique adapted to PHP’s Zend Memory Manager. The exploit needs two pieces of information to succeed:The Zend MM chunk base address. PHP’s heap allocator organizes memory into chunks. Knowing the chunk base lets the exploit predict where allocations will land.The libphp base address. PHP is compiled as a shared library (libphp.so). Knowing its base address lets the exploit calculate the address of zif_system, the function it wants to call.The exploit leaks both addresses through earlier producer/consumer rounds, each tuned to produce a distinguishable pattern in PHP’s error output or response behavior.With both addresses in hand, the final consumer request places a forged HashTable structure at the address PS(http_session_vars) still points to. The forged table’s pDestructor field contains the calculated address of zif_system. When PHP’s session initialization code processes this structure during cleanup, it invokes the destructor, and the attacker’s command runs.Where it lives in the sourceThe critical code path spans two files in the PHP source tree:ext/session/session.c contains the session module’s implementation. The upload progress callback (php_session_rfc1867_callback) runs during multipart parsing before RINIT. The session initialization function (php_session_initialize) reads PS(http_session_vars) early in the next request. The gap between the two, across the request boundary, is where the stale pointer survives.ext/session/php_session.h defines the PS() macro that accesses the session module’s global state. PS(http_session_vars) is a zval * that, during normal operation, points to the current request’s session data. When the request dies abnormally, this pointer is not reset.Put the full chain in one sentence: the producer corrupts PS(http_session_vars) and dies, the consumer fills the freed memory with a fake HashTable whose destructor is zif_system, and PHP’s own session initialization runs the attacker’s command.The Lab: Exploiting It YourselfReading about a vulnerability is one thing. Triggering a use-after-free across request boundaries is another. Here is a walkthrough of exploiting CVE-2026-109619 end-to-end in a lab environment, from a Kali box to code execution on the target.The EnvironmentThe lab target runs the Northstar Claims Gateway on PHP 8.4.26 with Apache mod_php in prefork mode, reachable from a Kali attack box at:http://northstar.localItemValueTargetnorthstar.localServiceHTTP on TCP/80RuntimePHP 8.4.26, Apache mod_php/preforkSAPIapache2handlerExploit script/root/Desktop/exploit-109619.pyFixed versionPHP 8.4.27 or laterStep 1: Enumerate the service and headersRun a focused service scan:nmap -Pn -sT -sV --version-light -p 80 northstar.localThen inspect the root response:curl -sI http://northstar.local/The nmap scan identifies Apache 2.4.69 on port 80. The HTTP response headers reveal X-Powered-By: PHP/8.4.26 and Server: Apache/2.4.69 (Debian). Apache is reachable, and PHP is running.Step 2: Inspect the applicationOpen Firefox in the Kali desktop and browse to:http://northstar.local/Northstar appears as a claims data gateway with an adjuster workspace, validation workflow, and service-status page. The application itself is not the target. The vulnerability is in the PHP runtime beneath it.Step 3: Discover hidden pathsRead robots.txt:curl -s http://northstar.local/robots.txtIt reveals three disallowed paths: /support/, /ops/, and /storage/.Enumerate both operational paths:ffuf -w /usr/share/dirb/wordlists/common.txt \
-u http://northstar.local/ops/FUZZ \
-mc 200,301,302,401,403 -ac -s
ffuf -w /usr/share/dirb/wordlists/common.txt \
-u http://northstar.local/support/FUZZ \
-mc 200,301,302,401,403 -ac -sThe directory enumeration reveals change-log.txt under /ops/ and runtime.php under /support/.Step 4: Gather runtime and deployment evidenceRead the operations note:curl -s http://northstar.local/ops/change-log.txtRead the diagnostics page:curl -s http://northstar.local/support/runtime.phpThe browser-rendered diagnostics page provides the same runtime evidence:Together, the change log and diagnostics page identify:PHP 8.4.26 as the runtime.apache2handler as the SAPI, confirming mod_php.A persistent single-worker prefork gateway.Session-backed multipart uploads and upload-progress telemetry still active.These four conditions, PHP 8.4.26 under apache2handler with a single persistent prefork worker and session upload progress enabled, are exactly the preconditions for CVE-2026-109619.Step 5: Locate the exploitThe lab provides a commit-pinned PoC from the public CVE-2026-109619 repository on the Kali desktop:cd /root/Desktop/
lsThe file exploit-109619.py is the lab’s driver script. It implements the full producer/consumer chain: heap leak, library leak, and final stale-reference trigger.Step 6: Run the producer/consumer chainUse three leak retries. The exploit performs five final-stage attempts (retries + 2). The || true suffix allows subsequent verification commands to run regardless of the driver’s local proof-file exit status, because the standalone target shares no filesystem with Kali:python3 exploit-109619.py \
-u http://northstar.local/service-status.php \
-c 'sh --proof /tmp/not-mounted \
--retries 3 || trueThe 13-byte command shcurl -s http://northstar.local/storage/uploads/flag.txtThe first response returns uid=33(www-data) gid=33(www-data) groups=33(www-data), proving the controlled command ran as www-data. The second returns the flag.If the heap or library leak misses on every attempt, rerun the identical exploit command. The PoC is deliberately calibrated to the pinned image and endpoint.What Just HappenedNo application vulnerability was exploited. No authentication was bypassed. The exploit targeted the PHP runtime itself: a worker-global pointer that was not reset when a request died abnormally. Two HTTP requests, one to poison the worker and one to reclaim the freed memory, turned a session-management lifetime error into arbitrary code execution.The defining failure is that request-scoped memory remained reachable through worker-global state after the request heap was freed. The code assumed that request shutdown always runs to completion. It does not, and the session upload progress handler creates a window where early initialization leaves state that late cleanup does not reach.The Fix in PHP 8.4.27PHP 8.4.27 corrects the lifetime management so that PS(http_session_vars) is properly reset during abnormal request shutdown, regardless of whether the session module’s full cleanup path executes. The pointer no longer survives the request boundary.Disabling session.upload_progress.enabled removes this specific producer/consumer route, because the early session initialization that sets PS(http_session_vars) before RINIT no longer fires. However, PHP’s own advisory warns that configuration changes are not a complete generic mitigation for stale worker-global state. The authoritative fix is updating to PHP 8.4.27 or later and restarting all Apache workers.DetectionDefensive evidence of exploitation attempts includes:Repeated multipart requests containing PHP_SESSION_UPLOAD_PROGRESS fields.Memory-exhaustion errors (Allowed memory size exhausted) occurring before normal application execution begins.Corrupted-heap or segmentation fault messages in Apache error logs, followed by worker crashes.Rapid worker replacement between pairs of similar multipart requests.Unexpected files or processes created by www-data or the web server user.ReferencesPHP security advisory for CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp)Pinned public CVE-2026-109619 lab PoCTry this exploit for yourself within Skill Dive’s CVE lab collection, regularly updated with the latest vulnerabilities.
The Crash That Runs Your Code: Inside PHP's CVE-2026-109618 (PHP2Shell)
Most vulnerabilities give an attacker something they can see: an endpoint that takes input it shouldn't, a parameter that ends up in a database query, a file path that escapes its directory. CVE-2026-109618 is stranger than that. The way in is to make PHP run out of memory at an unlucky moment, and then take advantage of the mess PHP makes while it is falling over.It is one of two bugs disclosed together in October 2026 under the name PHP2Shell. Both live in PHP itself, the interpreter that runs behind a huge share of the websites you use every day, rather than in any plugin or framework or anything a developer wrote. That is what makes it worth paying attention to. You can have perfectly clean application code and still be exposed, because the problem is a layer underneath your code.This post explains what the bug actually is and how a crash turns into remote code execution, then walks through exploiting it yourself in a lab environment, closing with how it was fixed.Vulnerability OverviewCVECVE-2026-109618. Its sibling, CVE-2026-109619, is a separate bug fixed alongside it and is not covered here.Affected productPHP itself (php-src), the core interpreterAffected versionsPHP 8.2 before 8.2.35, 8.3 before 8.3.36, 8.4 before 8.4.27, and 8.5 before 8.5.12TypeUnauthenticated remote code execution caused by memory corruption.Severity9.2 Critical on CVSS v4.0Confirmed impactUnauthenticated RCE over HTTP, demonstrated against Apache with mod_php on default settings, before any application code runs.Skill Dive CVE PHP2Shell: Exploiting PHP Memory CorruptionWhat PHP does when it runs out of memoryTo understand this bug you only need to understand one thing about how PHP works internally, and it is not complicated.Every PHP process has a memory budget, set by memory_limit. When a request tries to use more memory than that, PHP has to stop it. The clean way to stop would be to return an error back through every function that is currently running, letting each one tidy up as control passes back through it. PHP doesn't do that. The interpreter is a big body of C code, and an out-of-memory error can happen at almost any allocation anywhere in it, so instead of threading an error return through every one of those call sites, PHP handles it in one place.So PHP takes a shortcut that C programs have used for decades. It is called longjmp(), and the easiest way to picture it is as an emergency exit. Early in handling a request, PHP props the exit open and says, in effect, “if something goes badly wrong anywhere in here, jump straight back to this door.” PHP calls this its bailout. When an allocation fails, PHP doesn't walk back out the way it came in, through all the functions it is nested inside. It goes straight for the exit and skips past all of them.For most of PHP's history that was a fine trade. Jumping is fast and simple, and running out of memory was treated as a rare, fatal, nothing-more-to-do event. If a request died, it died.The catch is in that word skips. The functions PHP jumps over don't get to finish what they were doing, and they don't get to clean up after themselves. That is harmless right up until one of those half-finished functions left something behind that another part of PHP is going to look at later and assume is finished.The unlucky momentHere is where it goes wrong.The place this goes wrong is the window while PHP is still building the internal state a request needs: the tables and structures that hold the request together. In the advisory's words, “request memory is temporarily reachable before it is fully initialized.” The clearest example, and the one confirmed against Apache's mod_php, is during request startup, before your application code runs at all. PHP is parsing the incoming request body and setting things up, and for a brief instant some of those structures are visible to the rest of the engine before they are finished. The pointer to the structure exists, but the structure it points to isn't complete yet. (This isn't strictly a startup-only problem. The advisory notes PHP-FPM can reach the same bad state after startup too. Startup is just where it is easiest to see and where it has been confirmed.)Normally that instant passes in microseconds and nothing notices. But if an allocation fails during that instant, PHP does what it always does: it takes the emergency exit. The jump lands PHP back at the door, out of the half-finished work. Then PHP runs its normal end-of-request cleanup, because as far as it is concerned the request is over and needs tidying up. On Apache with mod_php this is guaranteed: the advisory notes that mod_php “unconditionally invokes the request shutdown procedure, even when request startup has failed.”That cleanup code finds the half-built structure, sees the pointer, and treats it as real, because under every normal circumstance it would be. It reads from memory that was never initialized, or that is already gone. That is the “corruption” in the advisory's title. Here is PHP's own description:“PHP uses longjmp() for out-of-memory (OOM) errors to exit the current context and abort handling of the request. Some contexts may not properly account for this scenario and leave request memory in an uninitialized state before performing an allocation. The subsequent request cleanup procedure may read or branch on this memory. Multiple OOM strategies can consistently trigger this condition and lead to remote code execution (RCE).”The PHP Foundation put it in plainer language: “If a request reached PHP's memory_limit at exactly the wrong moment, PHP could leave partially initialized internal data behind and later treat it as valid, corrupting memory.”So an attacker needs to do two things that, from outside a web server, they should have no business doing: make PHP run out of memory on command, and do it at the precise point where that broken-pointer window is open. The advisory's phrase “multiple OOM strategies can consistently trigger this” is the uncomfortable part. There is more than one reliable way to steer PHP into exhausting memory at a chosen spot. The researchers who reported it took it the rest of the way to running their own code on the server, as the account the web server runs under. The general shape of a working chain is now understood: reclaim the freed memory with predictable heap allocations, leak enough information to defeat ASLR, and steer a stale pointer into something PHP will execute. PHP rates the overall attack complexity as high, so this is not something a casual scanner trips into. But “hard” is not “safe,” and the lab walkthrough later in this post demonstrates that shape end to end.Why it doesn't matter how good your code isWith most web bugs, you have some say in your own defense. You can validate input, require a login, add a WAF rule, patch the vulnerable library.This bug sits underneath all of that. The corruption happens while PHP is starting up, before your application gets control of the request. On Apache with mod_php, PHP's advisory confirms an unauthenticated attacker can reach the flaw over HTTP, on default settings, before a line of your code runs. Wiz, one of the firms that found the bug, made the point directly: even a bare “Hello World” page on an affected version is exposed. Your code never gets a chance to weigh in.That said, not every way of running PHP is equally exposed, and it is worth being precise instead of scaring everyone equally. Here is what PHP's advisory actually claims for each setup:Apache mod_php: Confirmed. Unauthenticated RCE validated on default settings. mod_php runs its cleanup even when startup fails, which is exactly the path that gets abused.PHP-FPM: Source analysis suggests it is affected, but the advisory does not claim a full working exploit against it. When startup fails, FPM exits the worker, which makes the same trick harder. (One nuance: the PHP Foundation's own write-up says RCE was confirmed on FPM, but through application-level code paths rather than the before-your-code path. The clean way to state it: mod_php is the confirmed pre-authentication, pre-application case; FPM is reachable, but by a harder and more conditional route.)FrankenPHP: Likely susceptible to the same application-independent attack as mod_php, based on source analysis: the advisory says FrankenPHP also calls the request shutdown procedure unconditionally. Not separately demonstrated.LiteSpeed (LSAPI): The advisory says LSAPI “models FPM,” so application-specific exploits are “likely but unvalidated.” In other words, closer to the FPM case than the mod_php one.The short version: the confirmed worst case is mod_php, and the rest range from “probably” to “not proven.” That is useful for deciding what to fix first. It is not a reason to relax, because the fix and the urgency are the same across all of them.The Lab: Exploiting It YourselfHere is a walkthrough of exploiting CVE-2026-109618 in a lab environment, from a Kali box to code execution on the target.The EnvironmentThe lab target, ArchiveFlow Partner Exchange, is a mock partner document-exchange web application reachable from a Kali attack box at archiveflow.local. It runs the vulnerable PHP 8.4.26 under Apache mod_php/prefork, the exact deployment PHP's advisory confirms as the pre-authentication worst case. The exploit script, exploit-109618.py (Exploit-DB EDB-52704), is already staged on the Kali desktop, along with the wordlists used for enumeration.Before starting, it is worth knowing what makes this particular target reliably exploitable, because the public exploit chain depends on more than just an old PHP version:memory_limit=8M, while the exploit deliberately sends a larger multipart field to force the out-of-memory bailout.post_max_size=64M and upload_max_filesize=64M, so the oversized request is accepted far enough to reach PHP's parsing stage instead of being rejected upfront.session.upload_progress.enabled=On, which supplies the early session processing the vulnerable window needs.session.use_strict_mode=0, with cookies enabled, so attacker-influenced session state is accepted.A single Apache prefork worker, with keep-alive disabled, which makes the heap-reuse behavior the exploit depends on predictable.Error display enabled, so the in-band Set-Cookie disclosures the exploit relies on for its heap and libphp leaks can actually be recovered.No login or prior access to the target is required; the vulnerability is reachable by an unauthenticated attacker over plain HTTP.One more thing to know going in: the exploit's live `zend_string` carrier, the piece of corrupted memory that ultimately gets executed, accepts at most 14 command bytes. That is too short to carry a useful payload like a reverse shell one-liner. To make the lab completable without that constraint getting in the way, a small proof helper is pre-staged on the target at `/opt/lab/x`. When invoked, it writes `id` output to the web-served proof file `storage/uploads/p` and copies the lab flag to `storage/uploads/flag.txt`. The trigger command used against it, `shcurl -s http://archiveflow.local/robots.txtThe response identifies Apache and PHP 8.4.26. robots.txt points toward support, backup, and storage paths worth enumerating.Step 4: Discover application contentUse the installed DIRB wordlist with ffuf:ffuf -w /usr/share/dirb/wordlists/common.txt \
-u http://archiveflow.local/FUZZ \
-mc 200,301,302,401,403 -ac -sFuzz the backup/ directory for readable files:ffuf \
-w /usr/share/seclists/Discovery/Web-Content/raft-large-files-lowercase.txt \
-u http://archiveflow.local/backup/FUZZ \
-mc 200 \
-acThis reveals release-notes.txt. Inspect it:curl -s http://archiveflow.local/backup/release-notes.txtThe note confirms three important conditions: PHP 8.4.26, Apache prefork, and multipart intake processing, exactly the ingredients the vulnerability needs.Step 5: Confirm the runtime interfaceFuzz the support/ directory for files, appending the .php extension:ffuf \
-w /usr/share/seclists/Discovery/Web-Content/raft-small-words-lowercase.txt \
-u http://archiveflow.local/support/FUZZ \
-e .php \
-mc 200 \
-acThis reveals diagnostics.php. Access it at http://archiveflow.local/support/diagnostics.php.The relevant values are runtime PHP 8.4.26, interface apache2handler, host archiveflow. apache2handler confirms mod_php, which matters because request startup, shutdown, and worker lifetime all happen inside one persistent Apache process, the highest-risk deployment described in PHP's advisory.Step 6: Understand what's about to happenPHP 8.4.26 predates the fixed 8.4.27 release, and the target carries the reliability settings described above. The sequence the exploit drives:A large multipart request forces an out-of-memory bailout during request parsing, the exact unlucky moment described earlier in this post.Partially initialized request data stays reachable during cleanup instead of being discarded.Follow-up requests reclaim predictable Zend heap allocations in that freed space.Cookie data discloses the Zend MM chunk base and a libphp pointer, enough to defeat ASLR.The exploit derives ASLR-adjusted addresses and places a forged HashTable in the reclaimed memory.PHP invokes the forged destructor, which points to zif_system, PHP's internal system() implementation, and command execution follows.Step 7: Check the staged PoCpython3 ~/Desktop/exploit-109618.py --help | headStep 8: Execute the CVE-2026-109618 chainRun the exploit against a simple PHP endpoint. Two offsets are passed explicitly: --zif-offset is the offset of zif_system inside libphp.so, and --dtor-offset is the offset of ZVAL_PTR_DTOR. Both are fixed properties of this exact PHP build; they are relative offsets only, and the real ASLR-randomized addresses are leaked and recovered at runtime by the exploit itself.python3 ~/Desktop/exploit-109618.py \
-u http://archiveflow.local/status.php \
-c 'sh --proof-file '' \
--fetch /storage/uploads/flag.txt \
--zif-offset 0x465370 \
--dtor-offset 0x65eb60 \
--retries 5Successful output contains the leaked Zend MM heap chunk base, the leaked libphp base used to defeat ASLR, the calculated addresses used in the forged structure, confirmation of a successful final-stage execution attempt, and the retrieved proof. This is a build-calibrated memory-corruption chain: if all leak attempts miss, rerun the same command rather than changing the hostname, endpoint, or offsets.Step 9: Verify the impact independentlycurl -s http://archiveflow.local/storage/uploads/p
curl -s http://archiveflow.local/storage/uploads/flag.txtThe first response proves the command ran as the Apache worker account. The second is the recovered flag.What just happenedNo credentials, no login page, no application vulnerability of any kind. A crafted multipart request pushed PHP into an out-of-memory bailout at exactly the moment its own internal bookkeeping was unfinished, and the cleanup code that ran afterward trusted memory it should have thrown away. Everything downstream, the heap leak, the ASLR bypass, the forged destructor, is PHP acting exactly as designed on data it was never supposed to see in that state. The only thing application code could have done differently here is not run PHP 8.4.26.Fixed in: PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12. Per PHP's advisory, the patch removes longjmp() for out-of-memory handling entirely, replacing it with a delayed, graceful “soft” OOM triggered at the next VM safe point, and an immediate “hard” OOM that calls _exit() if memory use reaches a second, higher threshold, with no cleanup at all. The advisory states that updating to a fixed release is the only complete mitigation. According to Debian's security tracker, the end-of-life 7.4, 8.0, and 8.1 branches received source backports rather than official binaries; 7.3 and older have no fix at all.ReferencesPHP Security Advisory GHSA-w8hw-w9fx-j79w, “RCE via OOM corruption”CVE record, CVE-2026-109618PHP security team announcement (oss-security, Oct 21, 2026)The PHP Foundation, “Today's PHP security release and how we're strengthening PHP security”PHP ChangeLog (8.x)watchTowr, PHP2Shell analysisWiz, “PHP2Shell”Debian security tracker, CVE-2026-109618
Note: the sibling vulnerability, CVE-2026-109619 (“RCE via stale global state,” GHSA-6wmf-4rv5-p3rp), is covered separately.Try this exploit for yourself within Skill Dive's CVE lab collection, regularly updated with the latest vulnerabilities.
INE Launches Rebuilt eCDFP Certification to Validate End-to-End Digital Forensics and Incident Response Skills
Professional-level, hands-on certification prepares DFIR practitioners to preserve evidence, conduct defensible investigations across endpoint, storage, network, and log data, and produce investigation-grade reporting.
CARY, N.C., October 28, 2026— As digital investigations increasingly span endpoints, storage media, network traffic, and enterprise telemetry, INE, a leading global provider of hands-on technical training and certifications, today announced the launch of the rebuilt Certified Digital Forensics Professional (eCDFP) certification.Designed for experienced cybersecurity professionals, eCDFP validates the practical skills required to own digital forensics and incident response (DFIR) investigations end to end: scope and preserve evidence, perform defensible acquisition and triage, analyze endpoint and storage artifacts, correlate network and log telemetry, build defensible timelines, and communicate findings through clear, investigation-grade reporting.Organizations increasingly need practitioners who can do more than examine isolated artifacts or operate a single forensic tool. Real investigations require analysts to make sound collection decisions, preserve evidence integrity, reconcile conflicting timestamps, corroborate findings across multiple data sources, and document both conclusions and limitations. The rebuilt eCDFP is designed around that full investigative workflow.“Strong digital forensics is not just about finding an artifact. It’s about building a defensible story from evidence that can stand up to technical, operational, legal, and compliance scrutiny,” said Brian McGahan, CCIE Security and Director of Networking Content at INE. “The rebuilt eCDFP is designed to validate that complete workflow—from acquisition and evidence handling through cross-source analysis, timeline engineering, and reporting—so practitioners can demonstrate the skills required to support real-world incident response.”Unlike training centered on a single forensic product, eCDFP is vendor-neutral and focused on transferable investigation skills. The certification evaluates six core areas:Evidence handling, scope, standards, and defensibilityAcquisition, triage, and data validationEndpoint forensics, with Windows as the primary focus and Linux essentials for enterprise incident responseStorage media, file systems, recovery, and anti-forensicsNetwork, logs, and telemetry forensicsTimeline engineering, reporting, and case closureThe corresponding Digital Forensics Professional learning path is a rebuilt seven-course track designed as a progression from core DFIR methodology through full-stack investigations. Training covers defensible acquisition, Windows endpoint and application artifacts, file systems and storage, memory for incident response, network forensics, logs and Linux essentials, timeline engineering, reporting, and capstone investigations.eCDFP is built for DFIR and incident response practitioners, SOC Tier 2/3 analysts moving deeper into forensics, MSSP/MSP responders and IR leads, digital forensic examiners and technicians, threat hunters, detection engineers, and security consultants who are expected to produce repeatable, defensible investigation outcomes.The rebuilt Certified Digital Forensics Professional (eCDFP) certification and Digital Forensics Professional learning path will be available beginning today, October 28, 2026.To learn more about the Certified Digital Forensics Professional (eCDFP), visit the eCDFP certification page.About INEINE is the premier provider of online networking, cybersecurity, cloud, and IT infrastructure training and certifications. Through expert-led instruction, hands-on labs, and practical learning paths, INE helps individuals and organizations build the technical skills needed to succeed in today's rapidly evolving technology landscape. Serving Fortune 500 enterprises, government agencies, and IT professionals worldwide, INE is committed to developing real-world expertise that prepares learners for today's most demanding technical roles.
When a Valid TLS Chain Lies
The certificate was valid. The identity was not.Publication detailValueCategoryPKI / TLS / applied cryptographyEvidence current through26 October 2026Skill Dive CVE GhostTrust: Certificate Forgery and TLS Trust AbuseExecutive SummaryGHOSTTRUST LAB synthetic training evidence. The opening banking scenario and every GhostTrust name, certificate, key and transaction are fictional. They reproduce a failure class without using real compromised material.Imagine that Meridian Bank uses a clearing service to decide whether a $48,750 transfer should be released. A separate query to the genuine comparison origin returns HOLD. In the simulated attack path, the bank is preconfigured to contact a synthetic gateway controlled by Mallory. Network position alone should not be enough: the bank's TLS client is supposed to reject a server that cannot prove its identity. Mallory instead recovers the private key of a trusted intermediate certificate authority, signs a new certificate for the clearing hostname, and presents it to a stale client. The client reports a valid TLS chain and accepts the gateway-generated APPROVED response. GhostTrust assumes this attacker position; it does not demonstrate acquiring it or transparently intercepting the genuine origin.REAL INCIDENT confirmed public evidence. The public record establishes recoverable eMudhra intermediate CA keys, the affected certificate classes, the root-program response and the limits described below. It does not establish a real bank attack.GhostTrust demonstrates the cryptographic and trust-policy portion of that attack: weak-key recovery, unauthorized issuance, stale-chain acceptance and consumption of attacker-controlled data. It is also the central risk created by the October 2026 eMudhra incident: eight intermediate CA private keys were recoverable from public certificate material. Chrome's incident response classified six as TLS-issuing intermediates and two as Code Signing intermediates. The eMudhra root private keys were not compromised. The root failure carries no CVE of its own; it was a certificate-authority key-generation failure, not a flaw in TLS, P-384, or any cryptographic library, and not evidence that ordinary elliptic-curve keys can be guessed. The CVEs that do exist, Firefox’s CVE-2026-113470 and Go’s CVE-2026-111943, track client software that kept trusting the compromised certificates until updated, not a cryptographic break.It was a key-generation failure that reduced supposedly strong private values to a tiny search space. Chrome Root Program response eMudhra incident updateThe real attack also has hard prerequisites. Mallory must be in an active adversary-in-the-middle position, and the victim client must still accept a chain through an affected authority. Possession of an intermediate key does not passively decrypt recorded TLS sessions, recover historical plaintext, or place an attacker on the network path. Chrome reported that its CRLSet block and Certificate Transparency enforcement protected default Chrome before any certificate chaining to the six TLS intermediates had appeared in CT. The difficult tail was and remains in incidents like this non-browser software with stale or private trust bundles. Chrome Root Program response public client-remediation trackerI reviewed the public Mozilla incident record, the Chrome and Mozilla root-program discussion, the published certificate inventory, eMudhra's update current on 26 October, the GhostTrust target and helper source, and a supplied end-to-end lab transcript. I did not recover or use any real eMudhra private key, test a public service, or reproduce eMudhra's infrastructure. The runtime claims below are limited to the supplied, verified GhostTrust execution record.At a glanceQuestionEvidence-backed answerIncident typeRecoverable intermediate CA private keys caused by catastrophically small P-384 private scalarsAffected materialSix TLS-issuing and two Code Signing intermediate CA keysRoot private keysNot part of the reported compromiseTLS impersonation prerequisiteAn active adversary-in-the-middle position plus a client that still accepts an affected pathPassive or historical decryptionNot enabled by possession of an intermediate CA signing keyMalicious pre-disclosure exploitationNo public evidence identified; absence of evidence is not proof that no unseen attempt occurredGhostTrustA synthetic, controlled training implementation not eMudhra infrastructure and not a CVEChrome's response provides the six-TLS/two-Code-Signing classification and its CT and CRLSet findings. eMudhra says it found no evidence that the weak keys were recovered or exploited before disclosure, while its full root-cause analysis remained pending on 26 October. Chrome Root Program response eMudhra incident statementBackgroundThe certificate in the middleA browser or application rarely receives a leaf certificate signed directly by a root CA. More often, trust is delegated:trusted root CA
└── intermediate CA
└── server certificate for api.exampleThe root is the long-lived trust anchor. The intermediate performs day-to-day issuance. If an intermediate's signing key is recovered, an attacker can create new leaf certificates that appear to descend from that trusted hierarchy. TLS can still negotiate modern ciphers and encrypt every byte; the failed property is authentication. The client has established a confidential channel to the wrong endpoint.For an elliptic-curve key, the certificate publishes a public point Q, while the private scalar d should remain secret:Q = dGHere, G is the curve's standard generator. Recovering a properly generated P-384 scalar from Q is infeasible with current methods. That protection disappears when d comes from a tiny candidate set: derive dG for each candidate and compare it with the public point already present in the certificate. The algorithm has not failed; the private value never had the expected entropy.How the incident surfacedThe public reporter identifies only as Wayne. According to Wayne's Bugzilla timeline, a test against a CCADB certificate corpus first detected the broken EC keys at 16:27 UTC on 17 October 2026. At 18:05 UTC, Wayne sent the report and signed attestations to Apple, Chrome, Microsoft, Mozilla and eMudhra. Wayne later explained that Google's open-source paranoid_crypto found the weakness “out of the box”; CCADB had initially been intended as a quick corpus test. Wayne's discovery timeline Wayne's discovery explanationThe attestations mattered because they did more than point at suspicious public keys. Wayne signed a fixed message with each recovered intermediate private key, and the signatures could be checked against the corresponding public certificates. That establishes control of each signing key without publishing the private keys themselves. public proof descriptionIncident timelineDate and time (UTC)Event30 April 2025eMudhra says the eight intermediates were created during a key-generation ceremony.17 October 2026, 16:27Wayne's CCADB corpus test detects the weak EC keys.17 October 2026, 18:05Wayne reports the issue and sends per-key attestations to the root programs and eMudhra.17 October 2026, 19:45Chrome says it completed corroboration and landed an SPKI-based CRLSet block for the six TLS-issuing keys.18 October 2026, by 09:38The eight intermediate certificates are recorded as revoked for CA compromise.20 October 2026Mozilla publicly describes its response and publishes an NSS trust-store update removing the signing root for downstream users.26 October 2026eMudhra confirms a script error produced weak keys; its full root-cause analysis remains pending.Sources: Mozilla Bugzilla incident, Mozilla and Chrome root-program discussion, and eMudhra's incident statement.What is known and what is notThe published inventory identifies eight affected certificates using P-384 keys. Chrome's response separates them into six TLS-issuing and two Code Signing intermediates; the Code Signing constraints did not permit Chrome to construct a TLS path through those two. The affected intermediates were created on 30 April 2025. eMudhra says a script error during a key wrap/unwrap step produced a second, weak set of keys alongside the intended strong keys, and the weak set was published. Chrome Root Program response eMudhra's 26 October updateThat is the current boundary of the confirmed root cause. As of 26 October, eMudhra says the exact mechanism is still under investigation and promises a full analysis through the CCADB process. Speculation about test vectors, reference files or HSM behavior should not be presented as settled fact. The confirmed failure is weak published intermediate keys; the precise code path that produced them remains pending.In Bugzilla comment 43, eMudhra also stated that it had decided to exit the public TLS business. That is eMudhra's own incident-response statement; it is not a regulator sanction, and it does not mean customer migration was complete on 26 October. The same comment says the full report was still being prepared. eMudhra statement in Bugzilla comment 43eMudhra says it had not issued publicly trusted end-entity certificates from the eight affected CAs before disclosure. Researchers later created certificates with recovered keys as proof and research activity; those post-disclosure certificates demonstrate that the signing capability was real, not that malicious exploitation occurred before disclosure. eMudhra incident statement Mozilla Bugzilla discussionVulnerability DetailsFrom a public certificate to a signing capabilityA certificate is designed to publish its subject, issuer, validity period, permitted uses and public key. That normally reveals nothing practical about the private scalar. The eMudhra intermediates broke that assumption because the scalar space was extremely small. Anyone who obtained the public certificates could test candidate scalars offline, compare each derived public point with the certificate's public point, and stop on a match.Once recovered, the intermediate key carries the authority encoded in the certificate. For a TLS-capable intermediate, Mallory can generate a new leaf key, construct a certificate naming a service she does not own, and sign it with the recovered intermediate key. The forged leaf is not self-signed; it forms a cryptographically valid chain to the same root that a stale client already trusts.The following is a possible real-world abuse path, not the literal GhostTrust service topology:The diagram contains two different failures that must coincide. The CA failure gives Mallory a signing capability. The relying-party failure leaves the affected trust path usable. Neither one places Mallory on the network path, so DNS manipulation, a malicious proxy, BGP interference, gateway control or some equivalent active position is still required.Why a green lock can be the wrong answerCertificate validation answers a specific question: can the presented leaf be linked, under current policy, to an accepted trust anchor for the requested hostname? It does not independently know whether an intermediate key was generated safely. If the signature is mathematically correct and the affected intermediate is still accepted, the client can return “verification OK” even though an unauthorized party created the leaf.This distinction explains the urgency of root-program blocklists. Chrome says it blocked the SPKI hashes of all six TLS-issuing keys, covering both eMudhra-issued intermediates and Sectigo cross-certificates that shared those keys. Mozilla used OneCRL and then removed the relevant root from NSS for downstream consumers that do not receive Firefox's live protections. Chrome Root Program response Mozilla responseThe browser response and the client long tailChrome reported an important negative finding: before its 17 October block, no TLS certificates chaining to the six intermediates had been logged to Certificate Transparency. Because default Chrome requires CT for roots in the Chrome Root Store, such an unlogged forged certificate would have been rejected. That substantially narrows the demonstrated browser impact; it does not prove that every non-browser client was safe.Command-line tools, embedded devices, application containers, language runtimes and applications can carry their own CA bundle, omit CT enforcement, or handle revocation differently. Updating a desktop browser does not update a CA file baked into an old image. The public remediation tracker documents this distributed patch problem across operating systems, bundles, runtimes and libraries. client-remediation trackerExploitability AnalysisWhat the evidence establishesThe public attestations establish recovery of the eight intermediate signing keys. The inventory and root-program responses establish that six keys were associated with TLS-issuing intermediates and two with Code Signing intermediates. This is a real signing primitive, not merely a malformed-certificate observation.Impact versus evidenceStatementClassificationWhat the record supportsEight intermediate signing keys were recoverableConfirmed factWayne's signed attestations and independent Mozilla recovery established control of the keysSix keys could issue TLS chains; two were Code Signing constrainedConfirmed factChrome's root-program response distinguishes the two certificate classesAn unauthorized certificate can support TLS service impersonationRealistic conditional impactThe attacker must also control the network path, choose a valid hostname and reach a client that still accepts the affected chainGhostTrust's stale connector accepted an attacker-controlled APPROVED response while the separately queried genuine origin returned HOLDConfirmed lab-only resultThe supplied transcript records the synthetic legacy connector accepting APPROVED while the genuine origin returned HOLDThe weak keys were maliciously exploited before disclosureNot demonstratedeMudhra reports no evidence of pre-disclosure recovery or exploitation; the public record does not prove an unseen attempt was impossibleRoot keys, P-384 or TLS itself were brokenNon-claimThe reported compromise concerned intermediate keys generated with tiny scalar values, not a cryptanalytic break of the curve or protocolRecorded TLS sessions can now be passively decryptedNon-claimAn intermediate CA signing key enables certificate issuance; it is not the session secret or a server's historical leaf private keyFor TLS impersonation, Mallory still needs all of the following:A recoverable TLS intermediate key. The six TLS-capable keys satisfy this condition; Code Signing constraints do not automatically become TLS authority.An active network position. Mallory must cause Alice's connection to reach Mallory's endpoint or otherwise intercept and terminate it.A client that still accepts the affected path. A current browser with the emergency block and CT enforcement is a different target from a stale service using a bundled CA file.A matching leaf certificate. The certificate must satisfy hostname and relevant usage checks.A useful application exchange. Mallory can only read or modify traffic that the intercepted client sends through the impersonated endpoint.Under those conditions, the plausible impact includes service impersonation, credential capture, malicious update or API responses, and modification of application data in transit. The concrete GhostTrust result is narrower: one synthetic bank connector accepts an attacker-controlled settlement decision that differs from the separate genuine-origin response.What this does not proveThis incident should not be described as passive decryption. Eve, a passive observer with packet captures, does not gain historical plaintext simply because an intermediate signing key becomes known. Modern ephemeral TLS key exchange is not reversed by possession of a CA signing key.It also does not prove:compromise of an eMudhra root private key;compromise of eMudhra infrastructure or customer data;prior malicious exploitation of the weak keys;universal exposure of browsers after the emergency blocks;a flaw in the P-384 curve, OpenSSL or TLS itself;that every application trusting an eMudhra root would accept every affected chain; orthat certificate possession alone supplies DNS, routing or proxy control.eMudhra says the affected intermediates had not issued publicly trusted end-entity certificates before disclosure and that it found no compromise of infrastructure or customer data. Chrome's CT review found no pre-block entries chaining to the six TLS intermediates. Those are meaningful negative findings, while not being a proof about unlogged, non-CT clients. eMudhra's 26 October update Chrome Root Program responseDetection: find trust that outlived the incidentDefenders should start with the exact affected-certificate fingerprints and SPKI values in the published JSON inventory, then answer where those chains can still validate.Useful checks include:inventory OS, runtime, application, container, proxy and appliance trust stores separately;identify images or binaries that embed their own CA bundle rather than using the host store;compare bundle versions with the relevant vendor's patched release;test whether revocation is checked for intermediates, not only leaf certificates;inspect outbound TLS telemetry for affected issuer names, certificate fingerprints or SPKI hashes;search certificate inventories and CT monitoring for unexpected leaves chaining to the affected keys, while remembering that absence from CT does not clear non-CT traffic; andverify that emergency distrust reaches long-lived workloads after rebuild and redeployment, not merely the build host.The question is not just “did we patch Chrome?” It is “which TLS verifier made this connection, and which trust state did that verifier actually load?”Lab-value clarification: The private scalar 173 is an intentionally selected fictional value used only in GhostTrust. It is not an eMudhra private-key value. The real incident involved eight weak intermediate CA keys, six TLS-issuing and two Code Signing whose private scalars were reportedly below 256; the lab reproduces this vulnerability class without using real compromised key material.Proof of ConceptGHOSTTRUST LAB synthetic training evidence. This walkthrough uses only the fictional GhostTrust target and the supplied Kali desktop. It does not recover or distribute a real eMudhra key, contact eMudhra, or test a real bank.Screenshot provenance. Every image in this walkthrough is a curated lab-manual illustration captured from the synthetic GhostTrust environment. The screenshots are not raw evidence from the public eMudhra incident and should not be interpreted as such.OverviewThe 2026 eMudhra certificate incident involved intermediate CA private keys whose values had catastrophically low entropy. Public reporting described P-384 private values small enough to recover by testing only the candidate range 1..255. Control of a TLS-issuing intermediate key whose constraints permit server authentication can allow an attacker to issue unauthorized TLS certificates for sites they do not control.This lab safely recreates the same vulnerability class and exploitation mechanism with fictional certificates, domains, organizations, and banking records. The target is one standalone container, while you work from the separately provided Kali GUI.TaskInvestigate Meridian Bank’s settlement-verification path. Recover the weak private scalar belonging to the supplied fictional intermediate CA certificate, issue a certificate for the lab clearing hostname, demonstrate that the legacy connector accepts a response from the simulated attacker endpoint, and verify that the patched connector rejects the same certificate chain.ObjectiveBy completing the exercise, you will demonstrate:recovery of an extremely low-entropy P-384 private scalar;unauthorized leaf-certificate issuance from a compromised intermediate;TLS impersonation in a simulated, preconfigured attacker position;acceptance of attacker-controlled business data despite successful TLS validation; andmitigation through an updated trust policy.How the simulated scenario worksThe standalone target contains several logical services on one IP. The lab’s configured routing places a synthetic clearing gateway in the bank application’s clearing path. After the student-generated certificate is installed, that gateway presents the unauthorized chain and returns its own controlled settlement response.The genuine origin is a separate comparison endpoint. The gateway does not transparently fetch, decrypt, modify, or re-encrypt the genuine origin’s traffic. The exercise proves unauthorized certificate issuance, acceptance of an impersonating endpoint, and the security difference between stale and patched trust policies. It does not independently create or demonstrate a real network interception position.Lab ScenarioThe diagram below shows the complete GhostTrust workflow. The student first recovers the deliberately weak private scalar associated with the fictional Atlas intermediate CA. That recovered signing key is then used to issue an unauthorized TLS certificate for clearing.meridian-bank.local, which is installed on the simulated attacker gateway.The Meridian Bank application is already configured to contact this gateway for settlement verification. Its legacy connector accepts the unauthorized certificate because the stale trust bundle still contains the Atlas root. The gateway can therefore return attacker-controlled settlement data through a TLS connection that validates successfully. The patched connector removes the Atlas authority from its trust policy and rejects the same certificate chain.The genuine clearing origin is provided only as a comparison endpoint. The simulated gateway does not fetch, intercept, decrypt, modify, relay, or re-encrypt traffic from the genuine origin.Diagram-label clarification. The tested standalone lab uses clearing-origin.local for the separate genuine comparison endpoint, and the simulated gateway returns the decision APPROVED. The labels clearing.meridian-bank.local and SETTLED in this supplied overview graphic are schematic; the commands, captured outputs and written walkthrough below are authoritative.SolutionStep 1: Start from the provided Kali GUIUse the Kali desktop supplied by the lab platform. Do not SSH into Kali. The target names have already been mapped to the single target IP, so do not edit /etc/hosts.Open a terminal and confirm the four names resolve to the same target address:getent hosts meridian-bank.local
getent hosts clearing.meridian-bank.local
getent hosts clearing-origin.local
getent hosts gateway-status.localUsing one IP is intentional. The standalone target separates its logical services through HTTP host names and TLS Server Name Indication (SNI).Step 2: Download the student evidence kitCreate a working directory and retrieve the kit directly from the target:mkdir -p ~/ghosttrust-lab
cd ~/ghosttrust-lab
curl -fsS http://gateway-status.local:8080/lab/lab-kit.tar.gz | tar -xz
find . -maxdepth 2 -type f | sortlab-kit.tar.gz is the downloadable student-material bundle for the fictional GhostTrust exercise. The target serves it over port 8080 so every student receives the same public evidence, trust policies, and restricted helper scripts. The archive is not a running service and downloading or extracting it does not exploit the target.The archive contains:README.txt summarizes the fictional endpoints, starting workflow, and safety boundary.evidence/atlas-root.crt the fictional Atlas root CA certificate used to understand the affected trust hierarchy.evidence/atlas-weak-intermediate.crt the public P-384 intermediate CA certificate audited in the lab. It contains the public key, not the private scalar.trust/legacy-trust.pem the stale trust bundle containing both the fictional Meridian and Atlas roots. After the controlled certificate installation, this bundle accepts the student-generated Atlas chain.trust/meridian-root.crt the fictional Meridian root used by curl to authenticate the genuine clearing-origin.local endpoint.trust/patched-trust.pem the updated trust bundle containing only the Meridian root. Atlas has been removed, so the same student-generated chain is rejected.recover_weak_key.py an offline helper that tests the deliberately restricted scalar range 1..255 against the public point in atlas-weak-intermediate.crt. When it finds the matching lab value, it creates recovered-intermediate.key locally.forge_lab_certificate.py a restricted helper hard-coded to issue only for clearing.meridian-bank.local. It creates artifacts/forged-leaf.pem, artifacts/forged-fullchain.pem, and artifacts/forged-key.pem, then sends the chain and leaf key to the lab-only /install endpoint.The following files are generated while the student performs the exercise; they are not shipped inside the archive:recovered-intermediate.key the recovered fictional intermediate private key; andartifacts/forged-leaf.pem, artifacts/forged-fullchain.pem, and artifacts/forged-key.pem the fictional leaf certificate, complete presented chain, and matching leaf private key.The kit contains no real CA material, real compromised private key, packet capture, eMudhra certificate, or real bank data. It is lab scaffolding, not the vulnerability itself. The result is demonstrated only after the controlled recovery, issuance, installation, legacy-validation, and patched-rejection steps are completed inside GhostTrust.Confirm the required Python library is available:python3 -c "import cryptography; print(cryptography.__version__)"This one-line Python command only imports the required library and prints its installed version. It is a dependency check; it does not contact or exploit the target.Step 3: Inspect the Meridian Bank applicationOpen Firefox and visit:http://meridian-bank.local/The portal shows a pending transfer with reference MB-20481, beneficiary ACME-SUPPLIES, and amount $48,750.00. It also reveals that the clearing connector uses a legacy trust bundle whose last refresh was 28 days ago.The browser-facing portal uses HTTP in this standalone package so it does not require changes to the platform’s Kali trust store. The security exercise concerns the bank application’s authenticated outbound TLS connection to the clearing service.Step 4: Enumerate the standalone targetScan the relevant ports:nmap -Pn -sT --version-light -p 80,443,8080 meridian-bank.localThe ports represent:80/tcp bank portal and application API;443/tcp SNI-routed bank, clearing gateway, and genuine origin endpoints; and8080/tcp lab-kit and target-status service.Check the clean gateway state:curl -sS http://gateway-status.local:8080/status | jq .forged_material_present should be false and certificate_profile should be untrusted-bootstrap.Step 5: Establish the clean TLS behaviorAsk the bank’s legacy connector to validate the transfer:curl -sS "http://meridian-bank.local/api/transfer-preview?mode=legacy" | jq .The gateway is in the application’s configured path, but its bootstrap certificate cannot chain to a root in the legacy trust bundle. Network position alone is therefore insufficient.Step 6: Inspect the weak intermediateInspect the fictional certificate identity:openssl x509 \
-in evidence/atlas-weak-intermediate.crt \
-noout -subject -issuer -serial -datesInspect its key type and CA extensions:openssl x509 \
-in evidence/atlas-weak-intermediate.crt \
-noout -text | \
grep -E "Public Key Algorithm|ASN1 OID|CA:TRUE|Key Usage"The certificate uses P-384 (secp384r1) and has CA:TRUE. For an elliptic-curve key, the public point is Q = dG, where d is the private scalar. A correctly generated P-384 scalar has an enormous candidate space. In this exercise, d is known to be between 1 and 255, making direct comparison practical.Step 7: Recover the private scalarRun the supplied audit helper:How the recovery script worksrecover_weak_key.py reads the public P-384 point from the supplied intermediate certificate. It derives a public point for every candidate scalar from 1 through 255 and compares each result with the certificate’s public key. When the points match, the corresponding scalar is written locally as recovered-intermediate.key.This operation is performed entirely offline and does not modify any target service.python3 recover_weak_key.pyWhat recover_weak_key.py does and whyThis is a supplied cryptographic audit helper, not a programming exercise. It works entirely offline against the fictional certificate:It opens evidence/atlas-weak-intermediate.crt and extracts the P-384 public point Q. A certificate contains this public value; it does not contain the private scalar.It tests the deliberately restricted lab range 1..255. In Python, range(1, 256) includes 1 and stops before 256, so exactly 255 candidates are tested.For each candidate scalar d, the cryptography library derives the corresponding public point dG on the secp384r1 curve.It compares that candidate point with Q. An exact coordinate match means the candidate belongs to the certificate’s public key.When candidate 173 matches, the helper serializes it as an unencrypted PKCS#8 PEM file named recovered-intermediate.key and restricts the file to mode 0600. If no candidate matches, the script exits without producing a key.The recovered intermediate key is needed for the next step because it supplies the fictional CA signing authority used to issue the unauthorized leaf certificate. This works only because the exercise deliberately limits the search to 255 known candidates. It is not extraction of a secret field from the certificate, an ECDSA nonce attack, a general elliptic-curve attack, or a break of P-384.Confirm that the recovered key matches the certificate public key:openssl pkey -in recovered-intermediate.key -pubout -outform DER | sha256sum
openssl x509 -in evidence/atlas-weak-intermediate.crt -pubkey -noout | \
openssl pkey -pubin -outform DER | sha256sumThe first command derives the public key from recovered-intermediate.key. The second extracts the public key embedded in the certificate. Both are normalized to DER before SHA-256 hashing. Matching hashes show that the two public keys are byte-for-byte identical, confirming that the recovered private key corresponds to the certificate without displaying the private scalar itself.Step 8: Issue, inspect, and install the lab certificateThe kit was extracted directly into ~/ghosttrust-lab, so the forging helper is located at ~/ghosttrust-lab/forge_lab_certificate.py. Run it from the extracted kit directory:cd ~/ghosttrust-lab
python3 forge_lab_certificate.pyHow certificate forging and installation workforge_lab_certificate.py generates a new leaf key pair and constructs a TLS server certificate restricted to clearing.meridian-bank.local. It signs that certificate using the recovered fictional intermediate key.The helper creates the leaf certificate, the presented certificate chain, and the matching leaf private key. It then uploads the full chain and leaf key to the lab-only /install endpoint. After installation, the simulated gateway can present the unauthorized chain during a TLS handshake for the clearing hostname.What forge_lab_certificate.py does and whyThis second supplied helper demonstrates what possession of the fictional intermediate signing key permits. Students run it as provided; they do not need to write or modify Python code.The helper loads the Atlas intermediate certificate and recovered-intermediate.key, generates a fresh P-384 private key for the server, and builds a 30-day leaf certificate restricted to clearing.meridian-bank.local. The leaf is marked CA:FALSE, contains that exact DNS Subject Alternative Name, includes TLS server-authentication usage, receives a random serial number, and is signed by the recovered intermediate key using SHA-384.It then writes the leaf certificate, the presented leaf-plus-intermediate chain, and the new leaf private key beneath artifacts/. Finally, it sends the chain and matching leaf key to the lab-only /install endpoint so the disposable target can present them on the next TLS handshake for the clearing SNI hostname.The /install endpoint is exercise orchestration not the real vulnerability. It does not recover a key, create a network interception position, contact the genuine origin, or proxy its traffic. Its only purpose is to activate the student-generated identity inside this controlled target so the legacy and patched verification policies can be compared.The certificate construction happens on Kali. On the target, the installation endpoint checks that the uploaded certificate and private key can be loaded as a pair and that the certificate’s DNS SAN is exactly clearing.meridian-bank.local. It then stores that material in the lab’s temporary state. For a new TLS connection using that SNI hostname, the clearing service selects the installed certificate instead of the bootstrap certificate. The /install endpoint does not decide whether the chain is trusted; that decision is made later by the bank connector using either the legacy or patched CA bundle.The helper is hard-coded to issue only for clearing.meridian-bank.local. It creates these runtime files beneath the extracted kit:artifacts/forged-leaf.pem - the generated server certificate;artifacts/forged-fullchain.pem - the leaf followed by the fictional Atlas intermediate; andartifacts/forged-key.pem - the matching leaf private key, stored with mode 0600.Inspect the generated leaf certificate before testing it:openssl x509 \
-in artifacts/forged-leaf.pem \
-noout -subject -issuer -serial -dates -ext subjectAltNameConfirm that the subject identifies the fictional clearing service, the issuer is Atlas DV TLS CA - G3B, and the Subject Alternative Name contains DNS:clearing.meridian-bank.local.The helper defines BASE = Path(__file__).resolve().parent, so it resolves every path from the directory containing the script not from an arbitrary shell working directory. It reads evidence/atlas-weak-intermediate.crt and recovered-intermediate.key beside the script, creates artifacts/ beside the script, and then POSTs the full chain and leaf key to the lab-only http://gateway-status.local:8080/install endpoint.Standalone path warning: Do not use student-kit/ or drop/ in this student workflow. Those names belong to the source-delivery layout and the older multi-container range. The archive downloaded from the standalone target extracts forge_lab_certificate.py, recover_weak_key.py, evidence/, and trust/ directly into ~/ghosttrust-lab.Verify the clearing endpoint through the legacy trust bundle:openssl s_client \
-connect clearing.meridian-bank.local:443 \
-servername clearing.meridian-bank.local \
-CAfile trust/legacy-trust.pem \
-verify_return_error /dev/null | \
grep -E "subject=|issuer=|Verification"Verification: OK confirms that the unauthorized leaf is valid according to the stale trust policy.Why the legacy and patched results differBoth connectors receive the same server name, forged leaf certificate, intermediate certificate, and gateway-controlled response. The difference is their trust policy.The legacy bundle still contains the fictional Atlas root, allowing the forged leaf to build a trusted path through the compromised intermediate. TLS validation succeeds, and the application consumes the gateway-controlled business response. The patched bundle contains only the Meridian root. Because the Atlas chain can no longer reach a trusted root, certificate validation fails and the response is blocked.The genuine clearing origin remains a separate comparison endpoint and is authenticated using the fictional Meridian root.Diagram-label clarification. In the captured lab response, the legacy connector accepts the gateway-controlled decision APPROVED; SETTLED in this supplied conceptual graphic is shorthand for the attacker-controlled settlement outcome.Step 9: Compare the genuine and attacker-controlled responsesQuery the genuine clearing origin using its fictional Meridian root:curl -sS --cacert trust/meridian-root.crt \
"https://clearing-origin.local/v1/validate?reference=MB-20481&beneficiary=ACME-SUPPLIES&amount=48750.00" | jq .The genuine origin returns beneficiary ACME-SUPPLIES, decision HOLD, fraud score 87, and intercepted: false.Now repeat the bank’s legacy verification:curl -sS "http://meridian-bank.local/api/transfer-preview?mode=legacy" | jq .The response accepted from the simulated gateway contains beneficiary HARBOR-CONSULTING-8821, decision APPROVED, fraud score 3, and intercepted: true. These values differ from the independently queried genuine origin. The intercepted field is an explicit lab marker; it is not evidence that the gateway transparently proxied and modified the genuine origin response.Record the first flag:LAB{a_valid_chain_can_still_be_untrustworthy}TLS encryption still operated. The failure was authentication: the reconstructed intermediate key allowed the simulated gateway to present a chain accepted by the stale client, after which the client consumed content supplied by that impersonating endpoint.Step 10: Verify the patched trust policySend the same request through the patched connector:curl -sS "http://meridian-bank.local/api/transfer-preview?mode=patched" | jq .The patched trust bundle excludes the fictional Atlas authority, so the certificate path fails. Record the second flag:LAB{every_tls_client_needs_revocation_updates}Step 11: Review the audit trailcurl -sS http://meridian-bank.local/api/audit | jq .The events show the clean blocked request, the accepted legacy request after certificate installation, and the patched rejection. The same events can be viewed from the portal.Step 12: Connect the lab to real remediation workThe real incident required action in more places than browsers. An application might verify certificates through its operating system, a language runtime, a bundled CA file, a container base image, a proxy, an SDK, or custom code. Updating one verifier does not update all the others.A defensible response should include:Distrust the affected intermediate keys or issuing hierarchy in every active verification path, using the narrowest reliable control available.Update shared trust stores, language and runtime CA bundles, container base images, VPN clients, proxies, API clients, and embedded systems.Reload, restart, rebuild, or redeploy applications so the new policy is actually active.Test the application's real TLS path; a successful browser or unrelated curl test does not prove that another verifier is protected.Monitor Certificate Transparency and other available issuance telemetry for unauthorized certificates.Replace affected certificates and keys where required, and investigate whether interception occurred.Never work around new certificate errors by disabling verification.SummaryYou enumerated one standalone target image containing several realistic logical services. You retrieved only public evidence, recovered a deliberately weak P-384 intermediate private scalar, issued a lab-restricted clearing certificate, and proved that a stale application verifier accepted it.The legacy path consumed an attacker-controlled banking decision even though TLS verification succeeded. The patched path rejected the same certificate after the affected authority was removed from its trust policy. The lab does not implement transparent interception of the genuine origin; it demonstrates acceptance of an impersonating endpoint under a stale trust policy. This shows why CA-key compromise response must reach every browser, operating system, language runtime, application bundle, container image, proxy, and embedded verifier that authenticates TLS endpoints.ReferencesArs Technica The Internet goes on high alert after discovery of 8 compromised TLS certsMozilla Protecting Firefox users following the compromise of eMudhra intermediate certificatesCloudflare 8 eMudhra certificates are compromisedRemediationFor relying parties: distrust must reach the process that verifies TLSRevocation is useful only when the verifier that makes the connection actually obtains and enforces it. A response plan therefore has to follow the trust decision into every application, not stop at the browser or operating-system update.Apply vendor emergency updates and rebuild workloads with current trust bundles.Block affected SPKI hashes where supported. Because an SPKI block follows the key, it also covers cross-signed certificates that reuse that key the property Chrome relied on in its CRLSet response.Verify that revocation processing checks intermediate CAs, not only leaf certificates, and understand whether the application fails closed when revocation data is unavailable.Inventory independent and bundled stores in containers, language runtimes, appliances, proxies and long-lived processes; a host update does not automatically replace them.Remove the affected root only where a narrower block is unavailable and the resulting availability impact has been assessed.Enforce Certificate Transparency for public WebPKI use where the client ecosystem supports it.Retest the exact application connection after deployment. A successful browser test on the same machine does not prove that the application loaded the same trust state.Chrome's SPKI block and Mozilla's OneCRL response illustrate fast centralized controls. Their root-store changes addressed downstream consumers that did not receive those live blocklists. Chrome and Mozilla response threadFor certificate authorities: verify what was generated, not what the ceremony expectedThe key-generation process needs controls that survive script and wrap/unwrap mistakes:validate every generated public key for known weak-key classes before certificate issuance and publication;independently verify that the public key certified is the key pair intended by the ceremony;test wrap/unwrap and backup/restore steps as security-critical code paths;require two-person review and durable audit evidence for deviations from the approved ceremony procedure;continuously scan all disclosed CA certificates, not only roots, with tools such as paranoid_crypto or an actively maintained equivalent;compare CRL and OCSP signing behavior with the certified keys; andrehearse emergency intermediate distrust across root programs and downstream trust-store consumers.These are remediation principles, not a claim that eMudhra has completed them. As of 26 October, eMudhra says its full root-cause analysis and independent review are still pending. eMudhra incident statementRegression tests for GhostTrustFor the training target, the meaningful regression sequence is:bootstrap certificate is rejected;scalar recovery matches the fictional intermediate public key;the legacy bundle accepts the forged lab chain;the genuine and attacker-generated business responses differ;the patched bundle rejects the same chain; andreset removes the forged material and clears state.The lab should keep the exact-SAN restriction on /install and its fictional trust hierarchy. Expanding that endpoint would not improve fidelity; it would only broaden the training tool beyond its stated safety boundary.SummaryThe eMudhra incident was a failure of intermediate CA key generation, not a break in TLS or elliptic-curve cryptography. Wayne's publicly documented CCADB scan found recoverable keys on 17 October 2026; signed attestations established control, root programs reacted quickly, and eMudhra revoked the eight intermediates. Chrome classified six as TLS-issuing and two as Code Signing, while confirming that the root private keys were not the compromised material. eMudhra now attributes the weak published keys to a script error around a wrap/unwrap step, but its exact root-cause analysis remains pending as of 26 October.The potential TLS impact is serious but conditional: Mallory needs both an active network position and a client that still accepts the affected chain. That combination can turn a cryptographically valid connection into authenticated communication with the wrong endpoint. It cannot retroactively decrypt captured sessions, and the evidence does not establish malicious exploitation before disclosure.GhostTrust makes that narrow mechanism visible with fictional material. It recovers synthetic scalar 173, signs a leaf for a fictional clearing hostname, shows Verification: OK under a stale bundle, records acceptance of a different attacker-controlled settlement decision, and then shows the patched client rejecting the same chain. The most important operational lesson is simple: encryption can remain mathematically sound while authentication fails because the client's trust state is stale. A root-program response protects only the clients that receive and enforce it. Incident response is complete only after the exact verifier making the real application connection has loaded a trust policy that rejects the compromised authority.ReferencesMozilla Bug 2083449: eMudhra private-key compromiseMozilla and Chrome root-program response threadeMudhra certificate-security incident statementCommunity incident explainer and client-remediation trackerPublished affected-intermediate inventoryGoogle Paranoid Crypto
INE Expands Network Automation Training With Infrastructure as Code Learning Path for Cisco Engineers
Hands-on training helps network engineers build real skills in Python, APIs, Ansible, GitOps, Terraform, Network-as-Code, and moreCARY, N.C., October 23, 2026 — INE, a global provider of hands-on networking, cybersecurity, and IT training, today announced an expanded Infrastructure as Code (IaC) for Cisco Engineers learning path. The path helps network professionals move past device-by-device admin work. It also helps them build the automation skills they now need to manage infrastructure at scale.Infrastructure as Code is changing how networking teams handle configuration, deployment, and the full life cycle of their infrastructure. Manual changes can cause configuration drift within the infrastructure and make the environment hard to rebuild. With IaC, engineers define, manage, and test infrastructure through repeatable workflows.The training is led by INE instructor Rohit Pardasani, who has over 20 years of experience in designing, deploying and managing network infrastructure at scale. It builds both core and production-level skills across Python, API integration, rendering pipelines, Ansible, GitOps, CI/CD, Terraform, and Cisco Network-as-Code. Learners start by building an Infrastructure as Code mindset, and key ideas such as the desired state and convergence. This helps create automation workflows for real infrastructure.“Network automation isn’t about writing a few scripts to save time anymore,” said Pardasani. “Engineers need to think about infrastructure as a system: how changes are defined, tested, validated, deployed, and maintained over time. Infrastructure as Code gives network engineers a way to do that consistently and at scale.”The learning path focuses on practical engineering skills, including version control, state management, service abstraction, configuration rendering, API resilience, automated validation, and production-ready workflows.These skills matter more as networking, cloud, security, and software practices come together. Changes that engineers once made by hand now often run through automated pipelines. That makes Python, Git-based workflows, and declarative infrastructure management useful for network engineers, not just DevOps teams.For organizations, this shift leads to more consistent changes, better visibility into operations, and a measurable reduction in human errors . Engineers who understand both the network and the automation that controls it are infinitely better at troubleshooting failures and reviewing proposed changes. They’re also better at stopping automation from simply repeating mistakes faster.The Infrastructure as Code for Cisco Engineers learning path is available to INE Premium and Enterprise learners. It also includes hands-on labs where professionals can apply these automation concepts in real network environments.About INEINE is the premier provider of online networking, cybersecurity, cloud, and IT training and certifications. Through hands-on labs, expert instruction, and enterprise-ready learning solutions, INE helps individuals and organizations develop the technical skills needed to secure today’s increasingly complex digital environments. Serving Fortune 500 companies, government agencies, and IT professionals worldwide, INE is committed to building workforce readiness through practical, real-world training.
INE Wins SourceForge Fall 2026 Leader Award
User ratings place INE among elite technical training providers on leading software review platform.CARY, N.C., October 15, 2026 — INE, a global provider of cybersecurity, networking, cloud and IT training, today announced it has received the SourceForge Fall 2026 Leader Award. The recognition reflects praise from users who have reviewed INE on the software review and comparison platform.In its award notification, SourceForge recognized INE as a Fall 2026 category leader, a distinction reserved for select products that have earned exceptional praise through user reviews. To qualify, winners must receive enough recent, highly rated reviews to rank among the top 5% of favorably reviewed products on SourceForge, whose business software directory includes more than 100,000 products.INE combines expert-led instruction, hands-on labs, skills assessments and certification preparation to help technical teams build practical capabilities. Through its enterprise platform, managers can monitor learning progress, lab usage and assessment performance to guide training priorities and identify areas for development.The SourceForge award follows INE’s G2 Fall 2026 recognition, which included Enterprise Leader, Momentum Leader and Easiest Admin distinctions. Together, these recognitions highlight customer feedback across multiple review platforms. Organizations can explore INE’s enterprise training solutions and read customer feedback on INE’s SourceForge profile.About INEINE is the premier provider of online networking, cybersecurity, cloud, and IT training and certifications. Through hands-on labs, expert instruction, and enterprise-ready learning solutions, INE helps individuals and organizations develop the technical skills needed to secure today’s increasingly complex digital environments. Serving Fortune 500 companies, government agencies, and IT professionals worldwide, INE is committed to building workforce readiness through practical, real-world training.
Why Identity and Access Management Is a Core Cybersecurity Skill
IAM has a funny problem: people often notice it most when something breaks.A contractor can still reach a system after the engagement ends. A service account has permissions nobody remembers approving. A user is locked out of one application but not another. During an incident, the security team is suddenly piecing together authentication logs, group membership, and cloud permissions to understand what happened.
IAM sits underneath all of those situations. At its simplest, it answers three questions: who are you, what can you access, and should you still have that access?Those answers have become more complicated as organizations spread across cloud platforms, SaaS applications, remote workforces, APIs, and automated workloads. As a result, identity now connects work that used to live in separate corners of IT.
Access Follows the IdentityNetwork location once carried a lot of trust. Today, the same employee may move between a corporate laptop, a cloud console, a SaaS application, and a customer environment before lunch.Good access decisions have to travel with that person. They also have to account for device state, privilege, context, and policy. This is where IAM and Zero Trust meet in practice—not as slogans, but as the mechanics of deciding whether a request should be allowed.For practitioners, the useful skills are concrete: understanding authentication and federation, tracing authorization, recognizing excessive privilege, and troubleshooting access when the expected flow breaks.
Identity Systems Deserve the Same Security Attention as Other Critical InfrastructureThe recent disclosure of CVE-2026-76460 makes the point clearly. The vulnerability affects Cisco Identity Services Engine, used for network access control and identity-based policy enforcement. Cisco assigned it a CVSS score of 10.0 and confirmed active exploitation.Our companion analysis covers the technical details. From an IAM perspective, the interesting part is the position of trust these systems occupy. If the technology deciding who gets access is compromised, an attacker may be able to use pathways intended for legitimate users rather than attack each control individually.IAM belongs in architecture reviews and incident response for the same reason firewalls, endpoints, and cloud controls do: it influences what the rest of the environment will trust.
IAM Is Shared WorkIdentity incidents rarely stay with one team. A SOC analyst may spot suspicious authentication, while an IAM administrator traces the account. A cloud engineer checks permissions, and a network engineer reviews policy. Governance may need to show when access was granted and whether it was reviewed.
Nobody in that chain needs to know everything about IAM; however, they do need enough common ground to work from the same facts.
I would expect a technical team to be comfortable with identity lifecycle management, SSO and federation, MFA, authorization models, privileged access, service identities, and IAM logging. More importantly, they should be able to connect those ideas when something does not behave as expected.That shared understanding matters long before an incident, too. Routine changes are where IAM either stays healthy or quietly accumulates risk. A new employee needs the right access on day one without inheriting more than the role requires. A transfer should trigger a review instead of simply adding permissions on top of old ones. When someone leaves, access should disappear everywhere it is supposed to—not just from the primary directory. Those workflows sound ordinary, but they are where privilege creep, orphaned accounts, and weak ownership often begin.
Knowing the Acronyms Is Only the Starting PointSAML, OAuth, OIDC, RBAC, ABAC, PAM—the terminology can make IAM feel more theoretical than it is.
The practical questions are much easier to recognize. Why did this user get access? Where did this privilege come from? Why did federation fail? Which log would show whether an authentication event was legitimate? What happens to access when someone changes roles or leaves?Those questions shaped INE's Identity & Access Management Associate (eIAMA) learning path and certification. The training is vendor-neutral because real environments rarely depend on a single identity platform. The focus is on skills that transfer: lifecycle, authentication, federation, authorization, privileged access, monitoring, incident response, governance, and audit readiness.A product interface will change. The underlying access problem usually will not.For anyone working in security, cloud, networking, or infrastructure, IAM is becoming difficult to treat as somebody else's specialty. It’s part of the environment, and increasingly part of the job.
FAQWhat is identity and access management?IAM is the combination of technologies, policies, and operational processes used to manage digital identities and control access to systems, applications, and data.Why is IAM important to cybersecurity?IAM governs who and what can reach organizational resources. Weak authentication, excessive privilege, poor lifecycle management, or compromised identity infrastructure can create direct paths to unauthorized access.Is IAM only for identity administrators?No. Security engineers, SOC analysts, cloud administrators, systems administrators, network professionals, and governance teams all work with identity-related controls and data.What does eIAMA cover?INE's eIAMA learning path covers practical, vendor-neutral IAM skills across lifecycle management, authentication, federation, authorization, privileged access, service identities, monitoring, incident response, governance, and audit readiness.
CVE-2026-76460: Critical Cisco ISE Authentication Bypass Under Active Exploitation
Cisco has disclosed a critical authentication bypass vulnerability in Cisco Identity Services Engine (ISE) that organizations should treat as an immediate remediation priority.
Tracked as CVE-2026-76460, the vulnerability carries a CVSS 3.1 score of 10.0 and is already being actively exploited. The flaw affects both Cisco Identity Services Engine and Cisco ISE Passive Identity Connector (ISE-PIC), regardless of device configuration.For security and network teams, the risk is significant because ISE commonly sits at the center of Network Access Control (NAC) and identity-based access decisions. A compromise of that management plane can give an attacker considerably more than ordinary application access.What Is CVE-2026-76460?CVE-2026-76460 is an authentication bypass vulnerability in a Cisco ISE API.According to Cisco, the flaw results from insufficient authentication controls on an API endpoint. An unauthenticated remote attacker can send a specially crafted request to the vulnerable endpoint and bypass the web-based management interface's authentication controls.The CVSS vector is:CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:HIn practical terms, exploitation can be performed remotely over the network, requires no existing privileges, requires no user interaction, has low attack complexity, and can result in high impact to confidentiality, integrity, and availability.More importantly, Cisco states that successful exploitation may allow threat actors to obtain command execution with root privileges.That last point changes the incident-response calculation. Organizations should not treat this solely as an authentication issue. A successfully compromised node may need to be considered fully controlled by the attacker.Which Cisco ISE Versions Are Affected?Cisco states that the vulnerability affects Cisco ISE and ISE-PIC regardless of device configuration. Customers should update to at least the following fixed releases:3.1 → 3.1 Patch 123.2 → 3.2 Patch 113.3 → 3.3 Patch 123.4 → 3.4 Patch 73.5 → 3.5 Patch 4Cisco ISE 3.0 has reached the end of software maintenance, and Cisco advises customers still running it to migrate to a supported release containing the fix.There is no workaround that fixes the vulnerability. Cisco does, however, recommend infrastructure access control lists, or iACLs, as a temporary mitigation to restrict management and control-plane traffic reaching affected systems.Active Exploitation Raises the PriorityThis is not just a theoretical vulnerability waiting for proof-of-concept code, as Cisco PSIRT has confirmed active exploitation of CVE-2026-76460 and says the vulnerability was discovered while resolving a Cisco Technical Assistance Center support case.That means organizations should treat patching and compromise assessment as parallel activities. Updating a vulnerable appliance closes the vulnerability, but it does not establish that the appliance was never compromised before the update.How Defenders Should Investigate Cisco ISECisco recommends reviewing ise-kong/access.log for suspicious usernames and performing the check on every node in a distributed ISE deployment. Additional API gateway access logs can also be collected through a support bundle.Defenders should also review telemetry outside the appliance, including firewall and network logs, for activity such as unexpected uploads to external IP addresses or downloads from suspicious infrastructure.That external visibility matters because root-level access gives an attacker the ability to alter or remove evidence stored on the compromised system.Cisco goes further: when malicious activity is suspected, the company recommends re-imaging affected nodes and restoring configuration from backup as necessary rather than assuming local cleanup is sufficient.A practical response sequence is:Identify every Cisco ISE and ISE-PIC node and its current software version.Upgrade vulnerable systems to Cisco's fixed releases.Restrict management-plane exposure with appropriate infrastructure ACLs.Review access logs across every node for suspicious authentication activity.Correlate ISE activity with firewall and other external network telemetry.If compromise is suspected, preserve evidence and follow Cisco's guidance to re-image affected nodes.The Broader Lesson: Identity Infrastructure Is Security InfrastructureCVE-2026-76460 is another reminder that identity systems cannot be treated as administrative plumbing.Authentication, Authorization, & Accounting (AAA), privileged access, Network Access Control, and identity policy increasingly determine what users and systems can reach across an enterprise. Compromising the infrastructure enforcing those decisions can undermine controls far beyond a single application.That makes identity security a shared responsibility across networking, security engineering, IAM, and incident-response teams. INE's Certified Identity & Access Management Associate (eIAMA) addresses practical IAM skills across authentication, authorization, privileged access, monitoring, governance, and identity architecture. INE also provides hands-on cybersecurity training and networking training for teams responsible for securing the infrastructure connecting identities to enterprise resources.For CVE-2026-76460 specifically, however, the immediate priority is straightforward: inventory, patch, investigate, and do not assume patching alone rules out prior compromise.FAQIs CVE-2026-76460 being actively exploited?Yes. Cisco PSIRT confirmed active exploitation as of its September 16, 2026 advisory.Does CVE-2026-76460 require authentication?No. Cisco describes the vulnerability as remotely exploitable by an unauthenticated attacker.Is there a workaround?No complete workaround is available. Cisco recommends restricting management and control-plane access with infrastructure ACLs as a temporary mitigation while affected systems are upgraded.Can exploitation lead to root access?Cisco states that successful exploitation may allow attackers to obtain command execution with root privileges.
Globally Trusted Workforce Development and Industry Certifications
Have a question?
We’re here to help!
Whether you’d like more information on our training materials or are interested in a free demo, please contact us at any time.
