TP-Link / Omada Networks PSIRT

https://support.omadanetworks.com/en/bulletin/?bulletinsResourceTypeIdList=1111

Added 2026-08-22 as this run's single new candidate, to close a discovery gap the run hit directly: TP-Link's Omada gateway line is a common SMB / branch-office / public-sector edge device across Europe, and its August 2026 advisory (pre-authentication OS command injection in the OpenVPN server, CVE-2026-19586) reached this pipeline only through BSI CERT-Bund with the vendor's own per-model firmware table unread; the first surfacing pass concluded the vendor advisory was unreachable and composed from NVD instead. FETCH (verified 2026-08-22): the advisory LANDING and SEARCH pages at omadanetworks.com are a JavaScript-only application that returns no content to any transport, but the PER-ADVISORY document path IS server-rendered and reads cleanly through `python3 tools/fetch_source.py url https://support.omadanetworks.com/us/document/<id>/`, e.g. document 132084 for the August 2026 multi-CVE advisory, which carries per-CVE CVSS 4.0 vectors, root-cause text, exploitation preconditions, the vendor's own workaround, and a 19-row per-model/per-hardware-version fixed-firmware table that the CVE records do not reproduce. REUSABLE RECIPE, worth generalising beyond this vendor: the reliable way to obtain the document id is the referencing national-CERT CSAF record's external-reference field, BSI CERT-Bund's WID-SEC JSON carried it directly (`fetch_source.py bsi-csaf WID-SEC-2026-2964`), rather than trying to crawl the vendor's own single-page application. Candidate: promote to active after 3 contributing runs. | 2026-09-10 (S1): https://support.omadanetworks.com/us/security-advisory/ now 404s (Nuxt 'page404' response); the URL appears to have moved or been retired. No replacement URL found this run; needs a canonical-URL probe on a future run before it can be demoted or fixed. | 2026-09-13 intel run (S1): URL still 404s (Nuxt page404); needs a canonical-URL probe. | 2026-09-14 intel run (S1): listing URL still 404s (Nuxt page404), 3rd consecutive failure. Canonical-URL probe performed: the URL redirects to https://www.tp-link.com/us/press/security-advisory/, but that page is a static policy/contact page with no advisory listing rendered server-side (JS-hydrated), not a usable replacement. The listing endpoint itself appears genuinely retired; the working recipe remains the one already documented above (BSI CERT-Bund's WID-SEC CSAF external-reference field to obtain the per-advisory document id, then fetch support.omadanetworks.com/us/document/<id>/ directly) rather than crawling any top-level listing. Recommend a future run correct fetch_method/notes to route through that recipe by default instead of continuing to probe the dead listing URL every run. | 2026-09-15 intel run: fresh recipe (extract) tried; https://support.omadanetworks.com/us/security-advisory/ returns a live 200 but a site-rendered soft-404 ("page can't be found"), not a transport failure; the advisory listing has likely moved; WebSearch found no replacement URL. Recipe-fix candidate, not confirmed dead. | 2026-09-17 intel run (S1): listing URL https://support.omadanetworks.com/us/security-advisory/ still 404s. Probed the candidate replacement https://support.omadanetworks.com/en/bulletin/ directly (main-agent Phase 5 check); it returns HTTP 200 but the extracted body is only the site's cookie-consent banner text, no advisory listing content (same JS-hydrated soft-404 class already logged on 2026-09-15), so NOT applied as a url fix. The standing working recipe (BSI CERT-Bund WID-SEC CSAF external-reference field → per-advisory support.omadanetworks.com/us/document/<id>/) remains the only confirmed-working path; recommend a future run switch fetch_method/url to route through that recipe by default rather than continuing to probe listing-page candidates. | 2026-09-18 intel run (S1): RECIPE FIX APPLIED. The listing page https://support.omadanetworks.com/en/bulletin/ is a JS-rendered SPA -- plain extract/url returns only the cookie-consent shell (matching the 2026-09-17 finding above), but `python3 tools/fetch_source.py jina https://support.omadanetworks.com/en/bulletin/` successfully hydrates it and returns the full dated bulletin list (newest as of this run: CVE-2026-84941, Omada Controller XXE via SAML IdP metadata parsing, dated 2026-09-10). url/fetch_method switched to this jina-based recipe; the BSI CERT-Bund CSAF external-reference recipe documented above remains a valid fallback for a specific advisory's per-model firmware table. | 2026-09-19 intel run (S1): the bare listing URL (without the query filter) returns only the site navigation shell via jina -- no bulletin content -- which explains the repeated 404/empty flags even after the 2026-09-18 fix. The filtered URL with ?bulletinsResourceTypeIdList=1111 is confirmed to return the actual dated bulletin list (titles, CVE ids, dates); url updated to this filtered path. Most recent bulletin as of this run: CVE-2026-84941 (Omada Controller XXE), dated 2026-09-10, outside this run's 26h window. | 2026-09-29: fetch_method jina -> bridge: source_health reads it relevant and current over the direct transport, so it no longer needs the metered reader. (2026-09-29 operator-directed setup review) | 2026-10-02 (2026-10-02T0404Z-intel): `extract` of the bulletin URL returns only a cookie banner; `python3 tools/fetch_source.py url "https://support.omadanetworks.com/en/bulletin/?bulletinsResourceTypeIdList=1111"` returns the server-rendered HTML with every bulletin link and its MM-DD-YYYY date (regex href="/en/bulletin/<id>/" plus the date strings).