SSD Secure Disclosure

https://ssd-disclosure.com/advisories/

Added 2026-07-28 as this run's single new candidate. Coordinated-disclosure programme publishing original root-cause analyses and working proof-of-concept code for vulnerabilities it brokers (primary source for CVE-2026-61511, the vBulletin runMaths pre-auth RCE). Rated B: original vulnerability research, not a first-party vendor authority. FETCH: direct WebFetch returns a partial render; `python3 tools/fetch_source.py url <article-url>` succeeded this run via the reader fallback and returned the full advisory including the root-cause section. | 2026-08-08: rotation-priority catch-up succeeded via the jina reader; the landing page enumerated dated advisories and one article body was retrieved. A second article returned HTTP 202 direct and a robot-challenge page through the reader, so per-article retrieval remains partial. Listing extraction is no longer the blocker; per-article anti-bot is. | 2026-08-09: regression, the landing page itself now returns a Cloudflare-style robot-challenge interstitial through both the direct bridge and the reader, where on 2026-08-08 the reader enumerated the dated advisory listing successfully. Independently observed by S1 and S3. 403/anti-bot never demotes; needs a new transport, not a status change. | 2026-08-10: RECIPE FIX: per-article advisory pages fetch cleanly via `fetch_source.py url <URL>` (direct); it is the jina-reader path that returns a Cloudflare-style robot-challenge interstitial on this host. Try direct FIRST for article bodies and reserve the reader for the listing page. Recovered the Linux bridge STP UAF advisory this run after two prior runs logged it as a transport failure. | 2026-08-11: the listing page https://ssd-disclosure.com/ returned a Cloudflare-style robot-challenge (HTTP 202) to BOTH the direct transport and the reader this run, which inverts the 2026-08-10 recipe note in the other direction: direct works for a KNOWN per-article URL, but neither transport reaches the listing, so discovery has no entry point without an article URL in hand. Keep the direct transport for article bodies; for discovery, try a feed/sitemap path next run before treating the source as unreachable. | 2026-08-13: HTTP 202 Cloudflare robot challenge on both direct fetch and the jina reader again this run; no in-window content recoverable. Transport block, not death, no demotion. | 2026-08-18: fetch_method jina -> bridge. Pinning this host to the reader is indefensible on two counts: the pool is credit-exhausted, and this record's own 2026-08-10 note documents the reader as the transport that gets the robot-challenge interstitial here while the direct `url` transport reads article bodies. Observed this run: the two Unisoc advisory pages returned HTTP 202 with a 187-byte shell to the direct transport, so neither rung reached content today and the surfaced finding could not be published on the primary. Needs a feed/sitemap probe. | 2026-08-18: UNSOLVED flag worked this run: five direct paths probed with a desktop browser user agent (two advisory article pages, /feed/, /rss, /sitemap.xml and the WordPress REST posts endpoint) and every one returned HTTP 202, the anti-bot challenge interstitial rather than content. No direct rung reaches this host today. NOT demoted (an anti-bot challenge is transport blocking) and NOT muted to fetch_method blocked, because the host served article bodies to the direct transport on 2026-08-10 and the reader has not been tested this run for want of credit; the block is intermittent, so muting it would silence a research primary that works on other days. | 2026-08-19: advisory pages still unreadable: alternate transports attempted this run were the archive host (refused/connection-reset) and a feed/sitemap probe, both failing inside the 5-minute budget. The Unisoc backlog row stays open. | 2026-08-19 RECIPE CORRECTION (evidence-based, reverses the 2026-08-18 change): the block on this host is NOT a client-rendered SPA and is NOT intermittent; it is a site-wide SiteGround anti-bot interstitial. Every path probed this run (/feed/, /rss, /advisories/feed/, /sitemap.xml, /wp-sitemap.xml and both Unisoc advisory pages) returned HTTP 202 with a 170-190 byte body whose only content is a meta-refresh to /.well-known/sgcaptcha/?r=<the requested path>. No feed, sitemap or article path escapes it, so there is no direct transport to author a recipe against. The reader proxy runs page JS server-side from its own egress and is therefore the correct transport for this host; fetch_method is set back to jina on that basis. The 2026-08-18 note reasoned the reader receives the challenge; today's evidence is that the DIRECT transport receives it, which is the opposite. Deliberately NOT set to blocked: blocked means unreachable by every transport including the reader, and the reader has not failed on its merits here, only on credit. | 2026-09-03: anti-bot interstitial again on both direct bridge and jina fallback (listing page). This run's own source_health.py sweep separately classed it bridge-ok, so the block is content-shape-specific (listing page) rather than whole-host; no working per-article URL was in hand to test directly. Not demoted (403/429-class block, not a dead recipe). | 2026-09-04: 6th consecutive anti-bot interstitial on both direct bridge and jina fallback; no per-article URL in hand to test around it. Not demoted. | 2026-09-05 audit: 7th consecutive run blocked by Cloudflare Robot Challenge Screen on both direct bridge and jina fallback. | 2026-09-06: 8th/9th consecutive run blocked by the Cloudflare Robot Challenge Screen on both the direct bridge and the jina reader fallback (S1, S3 independently); no per-article URL in hand to test around it. Not demoted (anti-bot class block, not source death). | 2026-09-07: set fetch_method=blocked per the genuinely-unreachable-by-every-transport rule. S1 and S3 both independently confirmed a Cloudflare Robot Challenge Screen on direct bridge AND the jina reader fallback this run (10+ consecutive blocked runs); S3 additionally checked the ssd-secure-disclosure GitHub advisories mirror as a bypass route and found its last commit dates to 2020 (does not track current advisories). Stop re-flagging as unsolved every run; re-probe only if the operator reports the block has lifted. | 2026-09-10 audit note (S1/S3 rotation-priority retry): the 'blocked' flag no longer reflects reality, both the homepage (via S1) and the advisories listing plus individual advisory pages (via S3, both bridge url and extract) now resolve cleanly through the jina reader fallback. fetch_method corrected from blocked to jina; rotation_priority should clear on a second consecutive confirming run. No in-window item found this run (the two most recent posts predate the 24h window). | 2026-09-29: container egress gets the SiteGround sg-captcha challenge (HTTP 202, header `sg-captcha: challenge`, meta-refresh to /.well-known/sgcaptcha/ with an ipr:<egress-IP> token) on every path, and the reader pool is exhausted (402) - but agent-side WebFetch reads https://ssd-disclosure.com/advisories/ (10 newest advisory titles + links) and each article page (date, CVE, body) cleanly. Working recipe: WebFetch /advisories/ for the listing (undated), then WebFetch each advisory URL for its date and technical detail; fetch_method jina -> webfetch. Cadence ~2-3 weeks (2026-08-05, 08-17, 09-10). No feed/sitemap reachable. NOTE: tools/source_health.py content check exercises only fetch_source.py, so it will keep reporting unreadable/reader-quota for this host from the container; a false positive while WebFetch works. (2026-09-29T2134Z-audit) | 2026-09-29: fetch_method jina -> webfetch, as the record's own 2026-09-29 note says: WebFetch /advisories/ then each advisory for its date. The SiteGround captcha shown to container traffic makes source_health report it unreadable; that is a known false positive, not content death. (2026-09-29 operator-directed setup review) | Added 2026-07-28 as this run's single new candidate. Coordinated-disclosure programme publishing original root-cause analyses and working proof-of-concept code for vulnerabilities it brokers (primary source for CVE-2026-61511, the vBulletin runMaths pre-auth RCE). Rated B: original vulnerability research, not a first-party vendor authority. FETCH: direct WebFetch returns a partial render; `python3 tools/fetch_source.py url <article-url>` succeeded this run via the reader fallback and returned the full advisory including the root-cause section. | 2026-08-08: rotation-priority catch-up succeeded via the jina reader; the landing page enumerated dated advisories and one article body was retrieved. A second article returned HTTP 202 direct and a robot-challenge page through the reader, so per-article retrieval remains partial. Listing extraction is no longer the blocker; per-article anti-bot is. | 2026-08-09: regression, the landing page itself now returns a Cloudflare-style robot-challenge interstitial through both the direct bridge and the reader, where on 2026-08-08 the reader enumerated the dated advisory listing successfully. Independently observed by S1 and S3. 403/anti-bot never demotes; needs a new transport, not a status change. | 2026-08-10: RECIPE FIX: per-article advisory pages fetch cleanly via `fetch_source.py url <URL>` (direct); it is the jina-reader path that returns a Cloudflare-style robot-challenge interstitial on this host. Try direct FIRST for article bodies and reserve the reader for the listing page. Recovered the Linux bridge STP UAF advisory this run after two prior runs logged it as a transport failure. | 2026-08-11: the listing page https://ssd-disclosure.com/ returned a Cloudflare-style robot-challenge (HTTP 202) to BOTH the direct transport and the reader this run, which inverts the 2026-08-10 recipe note in the other direction: direct works for a KNOWN per-article URL, but neither transport reaches the listing, so discovery has no entry point without an article URL in hand. Keep the direct transport for article bodies; for discovery, try a feed/sitemap path next run before treating the source as unreachable. | 2026-08-13: HTTP 202 Cloudflare robot challenge on both direct fetch and the jina reader again this run; no in-window content recoverable. Transport block, not death, no demotion. | 2026-08-18: fetch_method jina -> bridge. Pinning this host to the reader is indefensible on two counts: the pool is credit-exhausted, and this record's own 2026-08-10 note documents the reader as the transport that gets the robot-challenge interstitial here while the direct `url` transport reads article bodies. Observed this run: the two Unisoc advisory pages returned HTTP 202 with a 187-byte shell to the direct transport, so neither rung reached content today and the surfaced finding could not be published on the primary. Needs a feed/sitemap probe. | 2026-08-18: UNSOLVED flag worked this run: five direct paths probed with a desktop browser user agent (two advisory article pages, /feed/, /rss, /sitemap.xml and the WordPress REST posts endpoint) and every one returned HTTP 202, the anti-bot challenge interstitial rather than content. No direct rung reaches this host today. NOT demoted (an anti-bot challenge is transport blocking) and NOT muted to fetch_method blocked, because the host served article bodies to the direct transport on 2026-08-10 and the reader has not been tested this run for want of credit; the block is intermittent, so muting it would silence a research primary that works on other days. | 2026-08-19: advisory pages still unreadable: alternate transports attempted this run were the archive host (refused/connection-reset) and a feed/sitemap probe, both failing inside the 5-minute budget. The Unisoc backlog row stays open. | 2026-08-19 RECIPE CORRECTION (evidence-based, reverses the 2026-08-18 change): the block on this host is NOT a client-rendered SPA and is NOT intermittent; it is a site-wide SiteGround anti-bot interstitial. Every path probed this run (/feed/, /rss, /advisories/feed/, /sitemap.xml, /wp-sitemap.xml and both Unisoc advisory pages) returned HTTP 202 with a 170-190 byte body whose only content is a meta-refresh to /.well-known/sgcaptcha/?r=<the requested path>. No feed, sitemap or article path escapes it, so there is no direct transport to author a recipe against. The reader proxy runs page JS server-side from its own egress and is therefore the correct transport for this host; fetch_method is set back to jina on that basis. The 2026-08-18 note reasoned the reader receives the challenge; today's evidence is that the DIRECT transport receives it, which is the opposite. Deliberately NOT set to blocked: blocked means unreachable by every transport including the reader, and the reader has not failed on its merits here, only on credit. | 2026-09-03: anti-bot interstitial again on both direct bridge and jina fallback (listing page). This run's own source_health.py sweep separately classed it bridge-ok, so the block is content-shape-specific (listing page) rather than whole-host; no working per-article URL was in hand to test directly. Not demoted (403/429-class block, not a dead recipe). | 2026-09-04: 6th consecutive anti-bot interstitial on both direct bridge and jina fallback; no per-article URL in hand to test around it. Not demoted. | 2026-09-05 audit: 7th consecutive run blocked by Cloudflare Robot Challenge Screen on both direct bridge and jina fallback. | 2026-09-06: 8th/9th consecutive run blocked by the Cloudflare Robot Challenge Screen on both the direct bridge and the jina reader fallback (S1, S3 independently); no per-article URL in hand to test around it. Not demoted (anti-bot class block, not source death). | 2026-09-07: set fetch_method=blocked per the genuinely-unreachable-by-every-transport rule. S1 and S3 both independently confirmed a Cloudflare Robot Challenge Screen on direct bridge AND the jina reader fallback this run (10+ consecutive blocked runs); S3 additionally checked the ssd-secure-disclosure GitHub advisories mirror as a bypass route and found its last commit dates to 2020 (does not track current advisories). Stop re-flagging as unsolved every run; re-probe only if the operator reports the block has lifted. | 2026-09-10 audit note (S1/S3 rotation-priority retry): the 'blocked' flag no longer reflects reality, both the homepage (via S1) and the advisories listing plus individual advisory pages (via S3, both bridge url and extract) now resolve cleanly through the jina reader fallback. fetch_method corrected from blocked to jina; rotation_priority should clear on a second consecutive confirming run. No in-window item found this run (the two most recent posts predate the 24h window). | 2026-09-29: container egress gets the SiteGround sg-captcha challenge (HTTP 202, header `sg-captcha: challenge`, meta-refresh to /.well-known/sgcaptcha/ with an ipr:<egress-IP> token) on every path, and the reader pool is exhausted (402) - Observation only: the agent-side WebFetch tool read https://ssd-disclosure.com/advisories/ (10 newest advisory titles + links) and each article page (date, CVE, body) cleanly, so WebFetch on /advisories/ for the listing and then each advisory URL for its date and detail would work. fetch_method stays jina: CLAUDE.md keeps WebFetch off article bodies, and tools/source_health.py exercises only fetch_source.py, so switching is the operator's decision alongside the CISA records (docs/audits/2026-09-29-quality-audit.md, recommendation 1). Until then the source is unreadable in-container. Cadence ~2-3 weeks (2026-08-05, 08-17, 09-10). No feed/sitemap reachable. (2026-09-29T2134Z-audit) | 2026-09-30 (v4.18, operator directive): WebFetch is NOT a working reader here. One live read of an advisory page at about 06:47Z (/unisoc-t612-lpe/, dated 2026-08-17), then 26 WebFetch calls over 18 URLs (the listing and its page 4, the home page, 15 advisory pages): 24 came back empty and 2 were replays of that cached read, and the page itself came back empty once the 15-minute cache lapsed (SR1, work/2026-09-30T0634Z-audit/SR1.findings.yaml). The container still gets SiteGround's captcha (HTTP 202) and the reader keys are out of credit (402). fetch_method jina (from v4.17's webfetch) so the health check keeps flagging the gap instead of reading it as handled; the reader is the one rung not yet tried with credit (it returned 402). Until then: discover with WebSearch `site:ssd-disclosure.com` (titles and snippets are leads only, snippet dates are unreliable), try WebFetch per advisory as best-effort, and corroborate from outlets that cover SSD advisories. (2026-09-30T0634Z-audit) | 2026-09-30, later: the reader pool was refilled at about 07:40Z (10 live keys), and with credit the reader also gets SiteGround's captcha ('Robot Challenge Screen'): 8 of 8 tries over /advisories/ and /unisoc-t612-lpe/ through jina, jina html, url and extract, and again on /advisories/ and /feed/ at 12:3xZ. No transport reads the host, so fetch_method jina -> blocked and the host joins TRANSPORT_BLOCKED_UNREACHABLE in source_health.py, which probes it with the direct transports only (no reader call, no retry), reports its wall as a handled coverage gap and flags the record again if a direct transport reads it or the page goes dead. Do not spend reader calls here. Discover with WebSearch site:ssd-disclosure.com (leads only), try WebFetch per advisory as best-effort, and corroborate from outlets that cover SSD advisories. (2026-09-30T0634Z-audit) | 2026-10-03 S1: still unreadable on every transport (direct GET answers HTTP 202 captcha, WebFetch empty); recipe unchanged, remains a coverage gap. (2026-10-03T0404Z-intel) | 2026-10-06 (S1): the listing now returns through `extract https://ssd-disclosure.com/advisories/` (reader fallback, undated; each article page carries Published Time); a direct GET still answers the captcha shell; newest advisory 2026-09-10. | 2026-10-06 (main agent): fetch_method restored from blocked to bridge: with trafilatura present `extract` reads the homepage directly and the /advisories/ listing through the reader fallback (the direct GET answers HTTP 202 captcha), so the source_health probe now reads relevant content; expect reader credit on the listing. | 2026-10-07 (S1): the listing and advisory pages returned a CAPTCHA on every transport this fire and only undated homepage titles read, so the 2026-10-06 note that the listing reads through the reader fallback did not hold. | 2026-10-08 (main agent): fetch_method set back to blocked. The 2026-10-06 reading that the listing comes through the reader fallback did not hold on 2026-10-07 or 2026-10-08: extract, the bridge, the reader and WebFetch all returned the robot-challenge screen or an empty body (S1, two consecutive fires), so no transport reaches the advisories; coverage gap, search for a corroborating publisher, do not retry. | 2026-10-09 (2026-10-09T0255Z-intel, main agent): source_health flagged needs-content-fix and `extract https://ssd-disclosure.com/advisories/` read the listing directly (trafilatura-direct, relevant advisory summaries) this fire, so fetch_method is back to bridge; the listing carries summaries but no dates, so item dates need the per-advisory page. The record has flipped between blocked and readable three times in four days (2026-10-06 restored, 2026-10-07/08 captcha on every transport, 2026-10-09 reads): treat it as intermittent and expect a robot-challenge on some fires. | 2026-10-11 (S1): `url --direct "https://ssd-disclosure.com/wp-json/wp/v2/posts?per_page=12&_fields=date,link,title"` returns dated JSON; newest post 2026-09-10. | 2026-10-20 (cleanup W6-02, 2026-10-11 audit recommendation 6 decided): keep. The premise of the recommendation (blocked on every transport) no longer holds: the 2026-10-20 probe read the listing as relevant (extract, direct transport), the 2026-10-11 S1 sweep found the dated WordPress posts API (`url --direct https://ssd-disclosure.com/wp-json/wp/v2/posts?per_page=12&_fields=date,link,title`), and three entries cite its advisories. The SiteGround captcha is intermittent and stays a handled, disclosed gap on the fires it hits. | 2026-10-24 (main): source_health flagged stale-content (newest item 2024-01-18) because the /advisories/ listing carries no recent dates; the WordPress posts API read cleanly today (newest post 2026-10-12, then 2026-09-10 and 2026-08-17), so the check now runs that call via health_cmd. The SiteGround captcha is intermittent and stays a disclosed gap on the fires it hits.