DEV Community: andreagomez

Rogue DHCP servers and the layer-2 trust that makes them work

andreagomez — Sat, 17 Oct 2026 09:00:42 +0000

Rogue DHCP servers and the layer-2 trust that makes them work

The Dynamic Host Configuration Protocol hands a device the address it will use, the router it should send traffic to and the name servers it should query. RFC 2131 defines the protocol and its message flow. RFC 3118 adds authentication for DHCP messages, and it is rarely deployed.

The trust model

A client broadcasts a request and accepts a response from whichever server answers first. Nothing in the base protocol lets the client verify that the response came from the network it believes it joined. An attacker on the same broadcast domain who answers before the legitimate server supplies the client with a gateway and resolver under their control, and the client will use them.

Failure points

Unsegmented networks where any device can reach the broadcast domain used for address assignment.
Test or lab DHCP servers connected to production segments.
Access points in bridge mode that extend the broadcast domain beyond the location where it was intended.
DHCP snooping enabled on the core switches but not on the access layer where the risk exists.
Devices set to act as a DHCP server because a configuration rollback restored an old role.

Controls

Enable DHCP snooping on access switches and define trusted ports explicitly, so responses from untrusted ports are discarded.
Segment the network so that a single broadcast domain does not span different security zones, and apply the segregation principles described in NIST SP 800-53 Rev 5.
Monitor for DHCP offers from unexpected sources and alert on them, since the event is uncommon in a stable network.
Avoid unauthenticated bridging where it is not required, and inventory access points that operate in bridge mode.
Confirm that a build process does not leave a device with the DHCP server role enabled by default.

Verification

Review the DHCP snooping configuration on the access layer, confirm the trusted port list, and check whether any segmented network permits broadcast traffic between zones.

References

RFC 2131, Dynamic Host Configuration Protocol. https://www.rfc-editor.org/rfc/rfc2131
RFC 3118, Authentication for DHCP Messages. https://www.rfc-editor.org/rfc/rfc3118
NIST SP 800-53 Rev 5, Security and Privacy Controls for Information Systems and Organizations. https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final

Which Sectors Should Look First: Reading the Gunra Victim Profile Against Externally Reachable Assets

andreagomez — Sat, 17 Oct 2026 08:00:42 +0000

Which Sectors Should Look First: Reading the Gunra Victim Profile Against Externally Reachable Assets

The 10 August 2026 Gunra advisory lists the sectors its authors observed on the group's leak site: healthcare and public health, financial services and insurance, critical manufacturing and construction, transportation systems and logistics, government services and facilities, utilities, academia, media and communications, retail, and professional and nonprofit services [1]. A list that broad describes the affiliate model, in which access is bought from initial access brokers and used against whichever organisation that access belongs to [1].
That distinction changes how a sector should react. A narrow list suggests a specialised threat; a broad list suggests opportunistic buying. Opportunistic buying rewards whichever organisation has left a usable entry point reachable.

What the advisory says about entry

The advisory maps initial access primarily to the exploitation of known vulnerabilities in internet-facing devices, including firewall and VPN appliances, and names CVE-2024-55591 and CVE-2025-24472, two FortiOS and FortiProxy authentication bypass issues [1]. It also records credential-exposure and Secure Shell access-control weaknesses in internet-facing VPN gateways observed by the Republic of Korea's National Police Agency [1].
None of these capabilities is sector-specific. A hospital, a water utility and a law firm running the same unpatched edge appliance present the same entry point.

Sector-relevant exposure, measured

The differentiator between sectors lies in which remote-access technologies they run and how many of those devices are externally visible. ZoomEye observations collected on 28 September 2026 provide the base rates [2]:
| Query | ZoomEye matches (28 Sep 2026) |
|---|---|
| service="rdp" | 16,471,930 |
| service="rdp" && country="US" | 3,353,836 |
| service="vnc" | 9,190,464 |
| app="Fortinet FortiGate" && country="US" | 5,845 |
Two readings matter here. The first is that remote-desktop and remote-administration exposure is enormous in absolute terms, so almost any organisation will find some externally reachable remote-access service if it looks carefully. The second is that a country filter is a triage heuristic, not an ownership statement; hosting providers and shared infrastructure distort any geographic slice.
These are counts of fingerprint-matched, externally observable services. They do not show which sector any given host belongs to, and they do not establish victim status for any organisation.

Turning a broad sector list into a short task list

Because the victim profile is broad, the practical response is generic and can be finished quickly.

Identify the remote-access technologies the organisation actually depends on, including those installed by integrators, and treat each as an entry point candidate.
Check whether each is reachable from the public internet, using queries whose fingerprints have been validated and recording the collection date.
Apply the advisory's mitigation directly: remote operational access should pass through a VPN or gateway device rather than terminating on the endpoint [1].
Verify the controls the advisory names as missing in one documented intrusion, namely account lockout and default-credential changes [1]. Sector context changes priorities within that list. A utility with an exposed controller and a media company with an exposed VPN gateway are solving the same first problem.

Why an external view helps a sector response

Sector-level threat reporting often arrives without an actionable local list. An external asset measurement converts the advisory into one by listing the services the organisation can see from outside, with dates and query text attached. It also catches the class the advisory singles out, devices installed by operators, vendors or system integrators that may not appear in routine attack-surface scans [1].

Limits

ZoomEye identifies externally observable services and their fingerprints. It does not attribute a host to a sector, an owner or an incident, and no count in this article should be read as a measure of how many organisations in a sector have been attacked.

Practical next steps

Use the advisory's sector list to justify the work, then run the exposure check for the technologies the organisation actually depends on. Remove remote access that cannot be justified, patch what remains, and repeat the measurement on a schedule so that the boundary does not drift.

References

[1] Cybersecurity and Infrastructure Security Agency et al., "#StopRansomware: Gunra Ransomware", advisory AA26-222A, 10 August 2026. https://www.cisa.gov/news-events/cybersecurity-advisories/aa26-222a
[2] ZoomEye, external asset queries collected on 28 September 2026. https://www.zoomeye.ai/
[3] MITRE ATT&CK, Enterprise matrix, version 19.1. https://attack.mitre.org/

CWE-35 or CWE-22? The Classification Split Around CVE-2026-85706

andreagomez — Fri, 16 Oct 2026 18:40:41 +0000

CWE-35 or CWE-22? The Classification Split Around CVE-2026-85706

Vulnerability overview

The public records for CVE-2026-85706 do not agree on its weakness classification. NVD carries CWE-22, improper limitation of a pathname to a restricted directory, attributed to cve@gitlab.com as the assigning source. The CISA Known Exploited Vulnerabilities entry lists CWE-35, path traversal with the trailing-dot variants. GitLab's own description uses neither code and says plainly that the issue is a path traversal in the repository commits API.
That divergence is small in wording and meaningful in practice, because classification drives which detection rules and scanner checks an organisation deploys.

Mechanism and exploitation conditions

The two codes describe adjacent things. CWE-22 is the parent concept: a program accepts a path and fails to confine it to the intended directory. CWE-35 is narrower and names a specific evasion family, in which sequences such as .../...// survive naive sanitisation and resolve into a traversal. The vulnerable behaviour GitLab describes, improper path confinement combined with missing authentication enforcement, satisfies CWE-22 directly. A CWE-35 label asserts something additional and more specific about how the path is crafted, and the vendor advisory does not publish the request that would confirm that detail.
The practical reading is that the two records are not contradicting each other. One describes the class of defect, the other describes a technique associated with it, and the CVE.org-sourced NVD text is the one that keeps to the general class.

Impact

For a defender, the split changes which artefacts to build. A rule written for CWE-22 watches for encoded traversal sequences arriving at file-serving parameters. A rule written for CWE-35 watches specifically for the dot-heavy variants that defeat a single-pass sanitiser. GitLab's own detections, which name a metadata.path parameter and generic file-path patterns, cover the wider class while the parameter-level rule catches the narrower technique. Deploying only one of the two leaves a gap on the other side of the split.

Affected products and versions

The classification applies across all affected ranges: 18.7 before 18.11.12, 19.0 before 19.0.9, 19.1 before 19.1.8, 19.2 before 19.2.6 and 19.3 before 19.3.2, in Community Edition and Enterprise Edition. Patching is identical for either code.

Exposure context

ZoomEye returned 1,317,044 matching assets for app="GitLab" on 25 September 2026, and the registry-scoped query vul.cve="CVE-2026-85706" returned zero. The same pattern of one record describing the product and another describing the identifier runs through this case: the useful artefact is a version check, whichever weakness code the tracker displays.
ZoomEye Search Link: https://www.zoomeye.ai/searchResult?q=YXBwPSJHaXRMYWIi

Remediation and mitigations

Upgrade to the branch-appropriate patched release, and where a classification field feeds a control choice, record both codes with their sources rather than overwriting one with the other. Building detection around the union of CWE-22 and CWE-35 coverage is defensible here, since the vendor describes a general path traversal and the catalog entry points at a specific technique within it. Reviewing the three published detections is the shortest path to that union without writing new rules from scratch.

References

NVD record: https://nvd.nist.gov/vuln/detail/CVE-2026-85706
CISA KEV entry: https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2026-85706
GitLab advisory: https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-3-2-released/

Three Secure Gateway authorization findings in one Splunk batch: 76265, 76272 and 76280

andreagomez — Fri, 16 Oct 2026 13:01:23 +0000

Three Secure Gateway authorization findings in one Splunk batch: 76265, 76272 and 76280

Splunk published SVD-2026-1001 on 2026-10-07. Reading it end to end matters, because CVE-2026-76272 shares an app and a root cause pattern with two higher-scoring neighbours.

What Splunk shipped

Splunk Enterprise versions 10.4.3, 10.2.7, 10.0.10 and 9.4.15 carry the fixes. Splunk Secure Gateway versions 3.10.11, 3.9.25 and 3.8.72 carry its own.

The three findings

CVE-2026-76272 is missing access control through the REST API in Splunk Secure Gateway, mapped to CWE-862 and scored 4.3 under CVSSv3.1. Splunk records it as VULN-71728. An account without the admin or power roles can make the gateway sign payloads the account controls.
CVE-2026-76265 is improper access control through REST API endpoints in Splunk Secure Gateway, mapped to CWE-284 and scored 6.5. Splunk notes there that privileged gateway functionality can be reached by accounts that should not have it.
CVE-2026-76280 is incorrect permission assignment for App Key Value Store collections in Splunk Secure Gateway, mapped to CWE-732 and scored 6.3. Alert and mobile-recipient data in those collections can be changed by an authenticated account without the admin or sc_admin roles.

Why the cluster matters

All three sit in the same application and all three are authorization defects, which points at a surface that needed hardening rather than a single slip. Two of them touch signing and recipient data that other workflows consume.

Affected versions and scope

Splunk Enterprise below 10.4.3, 10.2.7, 10.0.10 and 9.4.15, plus Splunk Secure Gateway below 3.10.11, 3.9.25 and 3.8.72. Where the app is not used, the advisory permits turning it off or removing it, noting that Splunk Mobile, Spacebridge and Mission Control depend on it.

Exposure context

ZoomEye returns 47,639 instances for app="Splunk". Use it to size how much Splunk faces the internet, not to count affected gateways.

Remediation

Upgrade both products to the fixed releases, or remove the app where its features are not in use.

References

Apache Airflow on 73,265 observed hosts: the scheduler that holds every connection string

andreagomez — Fri, 16 Oct 2026 09:20:46 +0000

Apache Airflow on 73,265 observed hosts: the scheduler that holds every connection string

A ZoomEye fingerprint query for app="Apache Airflow" (result list) returned 73,265 matching hosts at collection time, with sub_type=all, page 1 and page size 1. Airflow orchestrates data pipelines, and the count reflects how widely the pattern of scheduling work as code has been adopted.

What a workflow platform accumulates

Airflow's web interface listens on 8080 by default. The platform stores credentials for everything its pipelines touch, which in a mature deployment means databases, object storage, message brokers and third-party APIs. Connections are held in the metadata database and surfaced through the interface, and the variables store often holds tokens as well. The scheduler also runs code, since a directed acyclic graph is a Python file, and some versions expose a way to trigger runs and read task logs from the UI.

The original authentication was a single account, and the platform has since moved to support external providers and role-based access. Deployments that kept the default configuration are the ones that matter here, because a default login on a system holding production credentials is the whole problem in one line.

Checks for operators

Confirm that authentication is enabled and that the default account has been removed or moved to a strong credential managed outside version control.
Keep the web interface on an internal network or behind an identity-aware proxy, and review whether any DAG can be triggered by an unauthenticated caller.
Treat the variables and connections store as a secret store. Anything readable in the interface is readable by anyone who reaches it, so review what is stored there rather than only who can log in.
Review task logs for pipeline runs that no schedule explains, and watch for DAG definitions appearing that no deployment introduced.

What the count supports

A fingerprint match indicates a host that looks like Airflow. It does not confirm that the interface is reachable or that authentication is missing. Platforms of this class concentrate credentials by design, which is what makes the exposure question worth asking even when the number itself is only a starting point.

RouterOS management-plane exposure: measuring the SSH precondition

andreagomez — Fri, 16 Oct 2026 05:40:42 +0000

RouterOS management-plane exposure: measuring the SSH precondition

The September 2026 RouterOS vulnerabilities did not affect every MikroTik device equally. They affected devices whose administrative access was reachable from the internet. That condition, rather than the product name, defines which systems deserve the first hours of response.

Why SSH reachability is the deciding variable

The CERT Polska advisory of 5 September 2026 describes two flaws that combine in the SSH path. One let an unauthenticated client enter the connection protocol after a rekey and send an exec request; the other allowed the trusted RouterOS policy mask to be changed through a username handling error in the login path. The advisory states that exploitation required an unauthenticated SSH session to reach the RouterOS login helper. Reachability of SSH is therefore not a proxy for risk. It is the risk condition.
Externally measuring it converts a vague concern about a router fleet into a countable subset.

Measuring the subset

Four queries completed against live ZoomEye data on 15 October 2026 with sub_type=all:
| Query | Matching instances |
| --- | ---: |
| app="MikroTik RouterOS" && port="22" | 505545 |
| service="ssh" && app="MikroTik RouterOS" | 831147 |
| os="RouterOS" && port="22" | 9536 |
| app="MikroTik RouterOS" && port="8291" | 573 |
The first query is the tightest match to the published precondition: product fingerprint plus the SSH port. The second is broader because it matches any RouterOS asset for which SSH was identified as a service, including cases where the service was observed on a non-standard port. The third swaps the product fingerprint for the operating-system field and returns a much smaller set, which shows how sensitive these counts are to the identifier.
The port="8291" query is a separate observation. Port 8291 is the RouterOS management service, not SSH, and it is not the port named in the disclosure. Its count illustrates a different management surface on the same product and must not be added to the SSH figure.

Reading the numbers carefully

A count of external SSH reachability is not a count of compromised devices. It is not even a count of vulnerable devices, because banner data does not establish the RouterOS version. The reported figure of roughly 122,500 MikroTik devices exposing SSH, attributed to Shadowserver scanning and quoted in secondary coverage of the disclosure, is a different measurement taken on a different date with a different method. Report it as a separate observation rather than merging it with the counts above.

Implications

For triage, the SSH-reachable subset is the population to shrink. Every reduction in that subset directly removes the precondition described in the advisory, whether by firewalling the port, moving administration to a management network, or disabling the service where it is not needed. A baseline count, dated and reproducible, makes that reduction measurable rather than assumed.

References

CERT Polska, "Vulnerabilities in Mikrotik RouterOS software", 5 September 2026: https://cert.pl/en/posts/2026/09/mikrotik-routeros-cve/
CERT Polska advisories index, warning of active exploitation: https://cert.pl/
CERT.hr, CARNET National CERT incident statistics and September 2026 RouterOS advisory reference: https://www.cert.hr/u-prvih-devet-mjeseci-2026-godine-1203-incidenta-carnet-ov-nacionalni-cert-obiljezava-mjesec-kiberneticke-sigurnosti-nizom-aktivnosti/

Authenticating WebSocket connections at the edge

andreagomez — Fri, 16 Oct 2026 02:42:23 +0000

Authenticating WebSocket connections at the edge

A WebSocket session begins as an ordinary HTTP request and stops being one after the server answers with 101 Switching Protocols. Authentication middleware, reverse proxies and web application firewalls get one chance to inspect that request. After the upgrade they see a long-lived TCP connection carrying frames they usually do not parse. Teams that protect REST endpoints carefully often leave the socket path to whatever the framework does by default.

What the handshake carries

RFC 6455 defines the opening handshake, including Upgrade: websocket, Sec-WebSocket-Key and Sec-WebSocket-Version: 13. Because the handshake is an HTTP request, it carries cookies and an Authorization header when the client chooses to send them. That is where a session check belongs.
Browsers also send an Origin header, and it matters for one specific attack. Browsers do not apply the same-origin policy to WebSocket connections the way they do to fetch and XMLHttpRequest, so a page on one origin can open a socket to another origin and the browser attaches the target's cookies. Validating Origin on the server is the control that stops that cross-site WebSocket hijacking pattern, as documented in the OWASP WebSocket security guidance. Origin is a browser-supplied value, so it is useful for that purpose and useless as authentication, because a scripted client can send any value it likes.

Tokens in the URL

Passing a bearer token in the query string is common because the browser WebSocket API does not allow custom headers. It also writes the credential into access logs, proxy logs and anything else that records request lines. Issuing a short-lived ticket from the application and redeeming it during the handshake keeps the long-lived credential out of URLs. The Sec-WebSocket-Protocol header is sometimes used to carry a token; some proxies log it, so the same caution applies.

Authorisation is per message

A connection that authenticated once can stay open while permissions change. Subscription protocols need a decision at subscribe time for each topic, and a re-check when a role is revoked. A socket opened by an employee who leaves in the afternoon is still authenticated in the evening unless the application closes it.

Operational checks worth running

Confirm the proxy forwards Upgrade and Connection. nginx needs proxy_http_version 1.1 plus explicit header settings.
Log the identity and the authorisation decision when the connection opens, and log the close reason when a credential expires.
Test what happens when a session is revoked while a socket is open.
Confirm gateway and WAF policy covers the socket path and not only /api/.

References

RFC 6455, The WebSocket Protocol
OWASP WebSocket Security Cheat Sheet
OWASP, Cross-Site WebSocket Hijacking
nginx documentation, WebSocket proxying

Webform and Webform REST Flaws in the September 2026 Drupal Advisory

andreagomez — Fri, 16 Oct 2026 00:20:47 +0000

Webform and Webform REST Flaws in the September 2026 Drupal Advisory

Two related projects, two advisories

Advisory WID-SEC-2026-3554 covers contributed Drupal projects, and two of them belong to the same family. Webform is a widely installed module for building submission forms, and Webform REST exposes those submissions through a REST interface.
The advisory lists fixed releases for both. Webform is fixed in 6.2.12 and 6.3.1, covering two maintenance branches. Webform REST is fixed in 4.2.1.
Webform installations are common enough that the flaw class deserves attention on its own, because a form module is by design reachable by anonymous visitors.

Why a form module carries risk

A form builder accepts input from anyone who can reach the form. That input is stored in the database and later rendered, exported, or delivered by email. Each of those steps is a place where inadequate handling produces a security consequence.
Rendering stored submission data into an administrative listing is the classic stored scripting path. Delivering it into an export or a template that interprets content adds a second path. The advisory's shared impact sentence covers data manipulation, disclosure, and cross-site scripting, all of which fit a submission-handling module.

The REST layer

Webform REST adds an API surface on top of the stored submissions. An API that authenticates a caller but does not check whether that caller may read the specific submission is a disclosure and escalation risk, because submission records frequently contain personal data.
Sites that expose a Webform REST endpoint to the internet should treat the fixed release as urgent rather than routine.

Affected scope

The advisory covers Webform, Webform REST, Cloud, Project Browser, Commerce Decoupled Checkout, Mermaid Diagram Field, CookieCuttr, REST & JSON API Authentication, Stop administrator login, Tawk.to Live chat application, Editoria11y Accessibility Checker, AI CKEditor, Combined image style, CSS Usage Analyzer, Smart Content and Diba carousel slider. Fixed releases include Webform 6.2.12 and 6.3.1, Webform REST 4.2.1, Cloud 7.0.1, Project Browser 2.0.3 and 2.1.5, Commerce Decoupled Checkout 1.8.0, Mermaid Diagram Field 1.0.9, CookieCuttr 2.0.3, REST & JSON API Authentication 3.2.0, Stop administrator login 1.6, Tawk.to Live chat application 3.0.4, Editoria11y Accessibility Checker 2.2.23 and 3.0.9, AI CKEditor 1.4.3, Combined image style 1.0.7, CSS Usage Analyzer 1.0.2, Smart Content 3.2.1 and Diba carousel slider 3.0.2.
Sites running Webform or Webform REST below the fixed versions are in scope. Sites that run Webform without the REST companion still need the Webform update.

Remediation

Update Webform to 6.2.12 or 6.3.1 according to the branch in use, and Webform REST to 4.2.1. Then review stored submissions for unexpected content that would indicate prior exploitation, and check submission export logs for access from unfamiliar addresses.
Where Webform REST is not required, disable it. Removing a route from the application is more reliable than filtering requests to it.

References

CERT-BUND advisory WID-SEC-2026-3554, published 23 September 2026, high risk
CERT-BUND structured advisory record, product version list and referenced Drupal advisories
ZoomEye exposure query app="Drupal", executed 24 September 2026, exact count 436286

CVE-2026-76504: a Cisco SD-WAN Manager authentication bypass that needs no credential

andreagomez — Thu, 15 Oct 2026 21:40:49 +0000

CVE-2026-76504: a Cisco SD-WAN Manager authentication bypass that needs no credential

A network controller that manages branch connectivity is one of the devices an attacker would choose first. Cisco confirmed exploitation of CVE-2026-76504 in Catalyst SD-WAN Manager on 30 September 2026, the same day CISA added it to the KEV catalog, with a federal remediation deadline of 3 October 2026. The severity is 9.8, and the flaw is an authentication bypass in the API session path.

What the flaw is

The vulnerability concerns authentication handling in the API session of Catalyst SD-WAN Manager. A crafted request using encoded characters bypasses the check and reaches administrative API functionality as an authenticated caller. Cisco notes there is no alternative mitigation, so the software update is the only remediating action.

Why the SD-WAN controller is the target

The manager is the system that pushes configuration and policy to the routers and gateways across a distributed network. Administrative access to it is not local privilege on a single device; it is the ability to change routing, segmentation and access policy for the whole environment. An attacker who reaches that position can redirect traffic, add a tunnel, or disable a control, and the change looks like an authorised configuration update.

The pattern this belongs to

This is the fourth time this year that CISA has added a Catalyst SD-WAN Manager or Controller flaw to the KEV catalog, following earlier entries in February and June 2026. A product returning to the exploited list this often is a signal about the security model of the platform, not only about individual bugs. Management planes reachable from the internet and authenticated by the same service they manage concentrate a large amount of authority behind one check.

What to do

Update to the fixed releases Cisco published for Catalyst SD-WAN Manager. Because there is no alternative mitigation, exposure cannot be reduced by configuration alone.
Since exploitation is confirmed, treat deployment as an investigation as well. Review logs for access to the API paths involved from unexpected sources, and look for configuration changes that no administrator or automation made. Given the authority the controller holds, credentials it could reach should be considered for rotation after any confirmed compromise.

References

iThome reporting on the Catalyst SD-WAN Manager patch and KEV addition, 1 October 2026, https://www.ithome.com.tw/news/179329
Cisco security advisory for CVE-2026-76504, as summarised in the daily security intelligence report, https://blog.csdn.net/weixin_45635831/article/details/166945207

Compromise Assessment After CVE-2026-76504: Building a Defensible Investigation Order

andreagomez — Thu, 15 Oct 2026 10:41:08 +0000

Compromise Assessment After CVE-2026-76504: Building a Defensible Investigation Order

Vulnerability overview

CVE-2026-76504 is a critical authentication bypass in Cisco Catalyst SD-WAN Manager, disclosed by Cisco and added to the CISA Known Exploited Vulnerabilities catalog on 2026-09-30. The flaw is classified as CWE-177, improper handling of URL encoding, and carries a CVSS v3 base score of 9.8. An unauthenticated, remote attacker can reach the affected API and obtain administrative privileges on the controller.
CISA states that the entry was added based on evidence of active exploitation, and the required action is to apply vendor mitigations in line with BOD 26-04. Cisco's advisory and NCSC-NL advisory NCSC-2026-0395 both point at the same vendor fix, and Cisco has published indicators of compromise. NCSC-NL recommends checking controllers for those indicators before installing updates, so that pre-patch intrusion evidence is not overwritten.

Building the investigation order

If CVE-2026-76504 was exploited against a controller in your environment, the investigation has a natural shape, and the temptation to skip ahead is the main risk.

Start with scope: which controllers run affected releases, which of those were reachable, and for how long. Next, evidence: the application and network logs that cover the exposure window, checked against the vendor's indicators. Only then move to impact: what policy changed, what credentials the controller held, and what the controller could reach.

Each step constrains the next. Deciding impact before establishing scope produces conclusions that will not survive review. For a controller that orchestrates an entire overlay, a defensible investigation order is not a luxury; it is the only way the findings will hold.

Impact

Successful exploitation yields administrative control of the SD-WAN Manager. That is not an isolated host compromise. The manager is the policy and orchestration point for the overlay: administrators use it to push configuration to edge devices, manage VPN topologies, and change routing and security policy across the fabric.
Three consequences follow. First, an attacker with administrative access can alter policy in ways that are operationally indistinguishable from legitimate change management. Second, the credentials and trust relationships held by the controller expand the reach of the intrusion beyond the controller itself. Third, the compromise is not self-limiting: rolling back a controller configuration may not undo changes already propagated to edge devices.

Affected products and scope

Cisco addressed the vulnerability with a software update. The precise list of fixed releases is defined in the vendor advisory, and that document is authoritative; the affected series reported by secondary sources include 18.3.6, 18.3.7, 18.3.8, 17.2.10, 18.3.6.1, and 18.2.0, with further releases also listed.
Treat any controller that has not been updated to a vendor-designated fixed release as affected. Because the vulnerable component is the management API rather than a specific optional feature, exposure does not depend on unusual configuration. Organizations should confirm the running version and the platform model against the advisory rather than inferring status from a general familiarity with the deployment.

Exposure context

ZoomEye provides a bounded, verifiable estimate of how many matching assets are reachable. A query for the vendor's management fingerprint, app="vManage", returned 441 matching assets; a broader title-based query for "Cisco SD-WAN" returned 307, and title="SD-WAN" returned 84,870 assets from a wider set of vendors and products. A CVE-scoped query, vul.cve="CVE-2026-76504", returned 0, which is expected: ZoomEye does not index every CVE against every asset, and a zero there is not evidence of absence.
These are product-matching counts, not a confirmed-vulnerable population. A matching asset may already be patched, may be a lab system, or may be a fingerprint match that is not the affected component. The honest reading is that hundreds of assets present the vendor's management fingerprint to the internet, and each of them is a candidate for version verification.

Remediation and mitigations

The vendor fix is the primary action, and there is no substitute for it; reporting indicates that no workaround fully removes the flaw. Practical steps:

Inventory every SD-WAN Manager instance and record its running release and exposure.
Before patching, capture relevant logs and check for vendor-published indicators of compromise, following NCSC-NL's ordering advice.
Upgrade to a vendor-designated fixed release, following the advisory's upgrade path rather than a partial step.
Restrict management-plane access so the API is not reachable from untrusted networks; management interfaces should sit behind administrative controls, not on broad internet paths.
Rotate credentials and review trust relationships that the controller holds.
After patching, verify the running version and re-check exposure. For federal civilian agencies, BOD 26-04 sets a remediation expectation, and the KEV entry records a due date of 2026-10-03.

References

Cisco Security Advisory, cisco-sa-sdwan-webauth-xr8beuuU.
CISA KEV catalog entry for CVE-2026-76504, added 2026-09-30.
CISA alert, "CISA Adds One Known Exploited Vulnerability to Catalog", 2026-09-30.
NCSC-NL advisory NCSC-2026-0395.
NVD record for CVE-2026-76504.
ZoomEye query app="vManage", 441 matching assets.

Starting My Cybersecurity Journey

andreagomez — Thu, 15 Oct 2026 03:10:41 +0000

I’m starting this space to write about IT, networks, and cybersecurity. I’ve always been curious about how systems work under the surface — how traffic moves, how services connect, where things break, and how they can be made more secure. For me, learning isn’t just about reading concepts; it’s about setting things up, testing them, and seeing what happens when they don’t go as planned.

A lot of my learning happens in small home labs. I work with networks, virtual systems, security tools, and whatever else gives me a better view of how digital infrastructure operates. Some projects are simple configuration exercises; others are messy troubleshooting sessions that take hours to figure out. Both are useful.

This blog won’t be polished tutorials every time. It will be a mix of technical notes, experiment logs, setup guides, and the occasional failure report. I want to capture the learning process honestly — the confusion, the mistakes, and the small wins that make it interesting.

If you’re also into IT or cybersecurity, I hope you’ll follow along. I’ll share what I build, what I break, and what I learn from it.