42 Days From First Exploit to KEV: Where the Signal Was

The first public warning did not appear on X or in any feed keyed on CVE IDs. It appeared in the project's own GitHub issue tracker. On September 11, 2026, a Nextcloud administrator posted access logs that showed attacks on the built-in Collabora document server app (app name richdocumentscode). That was 32.5 days before the CVE ID became public and 42.2 days before CISA added the flaw to its KEV catalog (Known Exploited Vulnerabilities). On October 26, 2026, from 10:17 to 10:56 Singapore time (SGT), we sent 60 requests to EveryInfra (52 billed, $0.029576 in total). We compared the results with the NVD change history, the FIRST EPSS time series, and 24 other recent KEV entries.

The result is clear. A search of X by CVE ID returned 106 posts: zero before the CVE, and 80 after KEV. We labeled each post once with a rule written in advance (no second labeler), and 93.4% were reposts, bots, or promotion. The machine-readable SSVC field in the CVE record said "not exploited" for 9 days. EPSS stayed at 1.2% for 10 days.

In this article, an "auditable signal-to-response process" has five daily parts. You query project issue trackers, vendor forums, and a few social platforms for the names of your components (not only for CVE IDs). You save each raw response with its time. You match the results against your asset list and remove the noise. Then you upgrade, remove, or investigate, and you record who did each step, when, and on which evidence. The process tells operations and security teams which item comes first and why, but it does not predict exploitation or replace vendor advisories.

What we leave out

We write only about monitoring and response. We do not describe attack methods, exploitation details, or request formats. When we mention a compromise, we only say where an administrator posted, when, and what they reported. We hide personal account names and name only institutional accounts (for example CISA, CERT.LV, Italy's CSIRT, and Censys) and project maintainers. We do not judge any vendor's disclosure decisions, and we only put the times from public records next to each other.

For readers in US federal agencies, one detail matters most. Under BOD 26-04, CISA sets remediation deadlines from four inputs: KEV status, automatable exploitation, technical impact, and internet exposure. For this CVE, the KEV entry gave agencies three days and asked for forensic triage, which is the tightest deadline in the directive. That clock starts at KEV, but the attacks started 42 days earlier. This article is about that gap and about the public places where you could see it.

The criteria we wrote before the first request

At 10:16 SGT on October 26, before the first request, we wrote five criteria into our check file. At 10:29 SGT, before we opened the cross-section results, we added two more. The table below shows each criterion next to its result, and later sections give the source for each number.

Criterion 2 needs a note. On X, both search methods (by CVE ID and by product name plus symptom) returned zero related posts before the CVE. So X alone cannot show the difference. The difference comes from the project issue tracker and the forum, which are public places that you can watch by component name. We write "formal pass" for criterion 6 because a lead of 1 day and a lead of 30 days have very different value. A later section breaks that number down.

The main case: from the first attack log line to KEV

The CVE is CVE-2026-110447. According to Collabora's security advisory, it affects only one optional Nextcloud app, "Collabora Online - Built-in CODE Server". This app runs a copy of the document server inside the Nextcloud server. Standalone Collabora Online servers are not affected, and the Nextcloud forum warning adds that Docker and Linux distribution packages are also safe. The fix is version 26.4.303, and the advisory says that you must upgrade or remove the app (disabling it is not sufficient). The NVD record says the flaw was "exploited in the wild in September and October 2026".

We collected every time point that public records give to the second, and we used raw APIs, not summaries. The GitHub issues API gives the created_at time of the issue and of each comment. The Nextcloud forum runs on Discourse (API docs), so a topic URL with .json added gives the time of each post. The reserved and published times come from the API behind the CVE.org record. The time of each NVD field change comes from the NVD CVE change history API. The KEV time is dateReleased in CISA's KEV JSON, and all times in the table are UTC.

Two "70 minutes" and one "0.7 seconds" in this table deserve a closer look. Version 26.4.303 came out at 13:43 on September 11. Seventy minutes later, the first affected administrator opened an issue and said the systems had been compromised since the day before.

We think neither side knew about the other at that moment. The release notes had no security text, and the administrator upgraded only after someone in the issue asked. The second 70 minutes came on October 14. CVE.org published the ID at 02:27, and the first X post with the ID came 69.8 minutes later.

The 0.7 seconds is in the CVE.org API. The dateReserved value is 02:27:41.637 and the datePublished value is 02:27:42.315. So, for 33 days, the flaw did not have even a reserved ID. Any process that works by CVE ID had nothing to match during those 33 days. That is the core problem for every team whose intake starts with an ID.

We also found one place where a secondary source does not match the raw record. The Censys advisory of October 16 says that the reporter's logs show the first malicious request on September 16. But the issue body shows log lines from September 10 at 19:51 and September 11 at 09:56 (+0200 time zone).

The issue itself was opened on September 11, so it cannot quote a September 16 log line as the first request. We use the issue body from the GitHub API, because in a 33-day window one wrong date in a summary is a 6-day error. We copy the exposure numbers from the same advisory: 19,454 hosts and 103,350 web properties had the app installed. Censys says that not all of them are confirmed vulnerable, and both counts include the ARM64 build of the same app (1,001 hosts).

Why there was no CVE for 33 days

KEV has three firm requirements, which CISA lists on its criteria page. The flaw must have a CVE ID. There must be reliable evidence of active exploitation. There must be clear remediation guidance. This flaw met the second and third requirements on September 11, because the issue had reports from three administrators and the fix was out. The first requirement blocked it, so the 32.5 days without an ID made the total 42 days.

Collabora's blog post of October 14 puts two facts side by side. This year it received a very large number of AI-assisted security reports. And the time to get a CVE through GitHub went from about a day to many weeks. The post does not say that the first caused the second. It says that Collabora is now applying to become a CVE Numbering Authority (CNA) to shorten the wait.

The CVE.org record shows that MITRE was the final assigner and that reservation and publication happened in the same second. That looks more like MITRE as the assigner of last resort than a normal queue. We found no statement about this case, so we do not guess the cause.

This case is not unusual. In October, the security company Second Security published a study called The Patchless Window. It traced 18,594 open source CVEs from January to August 2026 back to the first public commit that fixed each one. The median time from public fix to public CVE was 5.1 days in January and 39.2 days in August. Collabora's gap was 32.5 days, which is shorter than the August median. So for open source components, "fix first, ID a month later" is becoming normal.

BleepingComputer's report of October 15 cited this study, and we checked the numbers on the study's own site. The Hacker News also reported the case. For a team that subscribes to vulnerability intelligence by CVE ID, the meaning is simple. On average, the first alert now arrives more than a month after the fix is public. During that month, the fix exists, but nobody tells you that it is a security fix.

There is one more piece of context. Starting on April 15, 2026, NIST no longer enriches every CVE. It prioritizes KEV entries, software that the federal government uses, and "critical software". NIST gives the reason as a 263% increase in CVE submissions from 2020 to 2025. On October 26, the NVD API still showed this record as Deferred (only the assigner's CVSS 4.0 score and CISA's SSVC). NIST's goal is to enrich KEV entries within one business day, and more than two days had passed since KEV.

For you, this means that many NVD fields can be empty before KEV and for some time after it. If you expect an NVD score to move a flaw to the top of your queue, that plan can fail in exactly this period. The description text was there from the first hour. The structured fields came later, and the next tests measure how much later.

Test 1: What social platforms showed before the CVE

If someone had watched this component on X, would they have seen it earlier? From 10:24 to 10:26 SGT on October 26, we ran three searches with the X (Twitter) Search Scraper API (twitter/search). Each search used a date window from September 1 to October 14. The first search used the app name richdocumentscode. The second used product name plus symptom words (nextcloud (hacked OR webshell OR compromised OR backdoor)). The third used only nextcloud collabora.

The results agreed. The first two searches returned 3 and 5 posts, and all were from October 14 or later, so zero came before the CVE. The third search returned 16 posts from before the CVE, and none of them mentioned a flaw or an intrusion. They were about Swiss federal staff and open source office tools, European digital sovereignty, and managed Nextcloud hosting. We also noticed that all three requests had until:2026-10-14, but the responses had 3, 5, and 6 posts from October 14 or later. The upper date limit ("before a specific date" in the X advanced search help) was not strict, so we filtered again on each post's posted_at value.

On Reddit, the Reddit Search Scraper API (reddit/search) always covers the last month. Our search on October 26 covered the period from September 26, which includes the 18 days before the CVE. At 10:42 SGT, a search for richdocumentscode sorted by newest returned 14 posts. All 14 were about this flaw, but none came before the CVE. The first was a security news repost at 20:04 on October 14, 17.6 hours after the CVE.

The most useful Reddit post came on October 22. An administrator in r/NextCloud described how the server was compromised through the built-in Collabora app, and the post had 52 comments. Thirteen seconds later, the same author posted it to r/Malware too. For Hacker News, we used the HN Algolia search API, and richdocumentscode returned zero results. For nextcloud collabora after September 1, the first related item was a link post on October 15 (22:06 UTC, 2 points, 0 comments).

We put the first related item on each platform in order, measured from CVE publication. The GitHub issue came 32.5 days earlier, and the Nextcloud forum came 10.7 days earlier. X came 0.05 days later, Reddit 0.73 days later, and Hacker News 1.8 days later. The YouTube Search Scraper API (youtube/search, 10 of 10 results with the ID) came 2.5 days later, and the LinkedIn Search Scraper API (linkedin/search, 8 of 10) came 4.0 days later. The Weibo Search Scraper API (weibo/search) returned 9 posts about a different flaw (PHP2Shell) and 1 digest that mentioned Collabora in one line. The Threads Search Scraper API (threads/search) returned 25 posts from only the last 19 hours, so it could not show a first sighting.

You can follow the logic of this table step by step. First, every public signal before the CVE was in a place that belongs to the project: the issue tracker and the vendor's user forum. Second, the authors there were affected administrators and maintainers, and their posts had logs and version numbers that you can check. Third, the first social posts came after the CVE, from security news accounts that read CVE records, not issue trackers. So the main watch must be "project issues and forums by component name". Social platforms amplify later and add victim reports, but in this case they were not an early warning system.

This conclusion has a limit. The victims here were small, self-hosted organizations, and they go to project issue trackers for help. If the victims are large enterprises, the first signal is more likely in a vendor's paid support channel. Public data cannot see that channel. So the pattern applies most to open source components that small teams run themselves.

Test 2: After the CVE, post volume follows KEV

At 10:26 SGT, we searched X once for CVE-2026-110447 with limit 200, sorted by latest. The response had 106 posts, so it did not reach the limit. We split the posts into three periods. Before the CVE there were 0 posts, and in the 9.7 days from the CVE to KEV there were 26. In the 2.3 days after KEV there were 80, including 49 on October 24 alone. Posts in the first 48 hours after KEV were 71.7% of the total.

The shape of this chart shows one thing clearly: on X, KEV is the amplifier, not the signal. The flaw was exploited in September, and the CVE description said "exploited in the wild" on October 14. Large security news accounts posted that same day. But the real wave of reposts came only after the CISA KEV notice. Many security news accounts and bots use the daily KEV update as their input, and many companies open tickets only for KEV entries.

For monitoring, this means that an alert on "X post volume for an ID jumps" would have fired after KEV in this case. Post volume tells you what people talk about now. It does not tell you who was already attacked. If your pipeline uses social volume as a trigger, it measures attention, and attention came last.

The language mix is also useful. Of the 106 posts, 68 were in English, 18 in Japanese, 5 in French, 4 in Spanish, 3 in Korean, and 1 in Chinese. For a US team, the important part is the Japanese share, because one Japanese post was the only firsthand compromise report on X before KEV. A watch that keeps only English posts would have missed it. If you filter by language, keep the languages of every country where your users run the software.

Test 3: 93.4% noise, and what it looks like

We sorted the 106 posts into 6 classes with a rule that we wrote in advance. To be clear about the limits: the 106 posts were labeled once, by the rule, and no second labeler checked them independently. So 93.4% is the result of one rule-based labeling pass, and its error range is unknown. Before you use it in a formal report, ask another person to label the 106 posts again with the same rule and report the agreement between the two passes. A "signal" adds a fact that is not in the CVE record or the vendor advisory. "Noise" has three classes: reposts of an advisory or news story, template bots and daily digests, and promotion or unrelated content.

The result: 80 reposts, 12 bots and digests, and 7 promotion or unrelated posts, for 99 posts (93.4%). Four of the 7 signal posts came from institutions with their own data: CERT.LV (Latvia), CSIRT (Italy), Censys, and CISA. Two were new facts from people who checked records. One post showed that the SSVC field contradicted the description, and one showed that NVD had a CVSS 4.0 score but no 3.x score. The last one was a Japanese administrator (October 23, 08:29 UTC) whose server got mining software through this flaw the week before.

Only 4 of these 7 posts came before KEV. So a team that read every post with the ID before KEV would have read 26 posts to find 4 useful ones. After KEV, the ratio was worse: 80 posts and 3 useful ones. Reading cost grows with KEV, and value does not.

Some of the 7 promotion and unrelated posts are types that you will see again with other flaws. Put them in your noise rules. There were posts that used the headline to promote a crypto token, and product ads for "connect an AI bot to a URL and get alerts". There were "bug bounty tips" posts that tell people how to find and test unpatched systems; we removed them and do not repeat them. One general comment about "every week feels like the sky is falling" matched only because it had the ID.

Noise is not only on X. In the 7-post Nextcloud forum thread, posts 3 and 6 came from the same new account. Both linked to an outside page with a "free 30-second self-test". Post 7 was a note from the community lead that said the two links were nearly identical and that the team watches for spam. On Weibo, 8 of the 10 results were the same PHP2Shell text from 8 accounts within 2 seconds, which is a typical account-farm pattern. On Threads, 6 of the 25 results for "Nextcloud Collabora" were Italian posts that used the verb "collabora" ("works together").

Test 4: Machine-readable risk fields were slower than the text

Many vulnerability pipelines do not read the description text. They read structured fields. One source is the three SSVC decision points that CISA writes into CVE records through its Vulnrichment project: exploitation, automatable, and technical impact. The other is the daily EPSS score from FIRST, which estimates the probability of observed exploitation activity in the next 30 days. The BOD 26-04 directive uses KEV status, automatable, technical impact, and exposure to set federal deadlines, and CISA supplies three of them through Vulnrichment.

We used the NVD change history API to get every change to this record's SSVC data. We used the EPSS API to get the time series. The CVE description said "exploited in the wild" from 03:17 on October 14. The SSVC data changed as the table shows.

So, for 9.7 days the description said "exploited", but the structured fields first were empty and then said "not exploited" for 9 days. They changed to "exploited" only 47 minutes after KEV. EPSS stayed at 1.2% for those 10 days (about the 68th percentile at the time) and reached 12.3% only on the second day after KEV. A rule such as "open a ticket when SSVC is active or EPSS is above 10%" would have fired 1 to 2 days after KEV. That is 11 days after the description text.

One X user saw this mismatch. At 21:03 UTC on October 23, the user posted an update. KEV had added the flaw about 6 minutes after their first post about the mismatch, and SSVC now said active. The post told readers to pull the data again if their pipeline had the old value. It also noted the federal due date of October 26. Among the 106 posts, it was one of the few with direct value for a pipeline.

This does not mean that SSVC and EPSS have no value. The EPSS FAQ says that EPSS is not a full risk score, and SSVC is an analyst judgment that needs evidence. Our observation is narrower: while the evidence existed only in a project issue tracker, neither field picked it up. Use structured fields to sort, not as a gate. Add a separate text rule for phrases such as "exploited in the wild" in the description.

Test 5: 24 recent KEV entries, and how early X was

One case is not enough. We took all 30 entries that KEV added from September 26 to October 23. Six had old IDs from 2015 to 2025 (for example, ProFTPD and BIND from 2015). For the other 24, we searched X once per ID with twitter/search from 10:28 to 10:41 SGT, with limit 200. For the KEV time, we used the first KEV annotation in the NVD change history. That annotation comes minutes to hours after CISA's release, so it is an upper bound that makes the X lead slightly too large. This differs from the main case, which uses dateReleased in CISA's KEV JSON (19:30 on October 23). The NVD KEV annotation for the same CVE came at 20:17, 47 minutes later. Older catalog versions do not give a release time per entry, so the cross-section uses the NVD annotation for all 24, and the main case appears there as 9.7 days on the same basis.

The result: 23 of the 24 (95.8%) had at least one X post with the ID before KEV, which formally meets criterion 6. But the median lead, computed from the unrounded values, was about 1.16 days (the 12th and 13th values are 1.12 and 1.19 days), and only 13 of the 24 led by more than 1 day. More important, for 17 CVEs the first X post was within 0.3 days of NVD publication. The reason is the gap between NVD and KEV. For 12 of the 24, KEV came on the same day as NVD or the next day, mostly for vendor-confirmed zero-days (Citrix NetScaler, Fortinet, Ivanti). X looks early only when that gap is long (Atlassian 10 days, Ahsay 10 days, our main case 9.7 days), and that lead comes almost entirely from the CVE itself.

Sort the NVD-to-KEV gap by calendar days and the shape is clearer. The gap was 0 days for 9 CVEs, 1 day for 3, and 2 days for 2. It was 5, 6, and 9 days for one CVE each, 10 days for 3, and 27 days for 4. The median was 1.5 days.

So this month's KEV entries fall into two groups. In the first group, the vendor confirms a zero-day, and the CVE and KEV arrive almost together. In the second group, the CVE was public long before, and the evidence of exploitation came later.

In the first group, X helps you see an urgent vendor advisory faster, and the lead is a few hours. In the second group, the X lead depends on whether anyone noticed the CVE after publication. The Plex case shows that nobody may mention it for three weeks. Also, 6 CVEs had X posts with the ID before NVD added them, usually because the vendor advisory gave the ID first. So when you build a timeline, do not treat the NVD receipt time as the time the ID became public.

The exception is the 4 Plex Media Server CVEs. NVD published them on September 23, but the first X post with these IDs came on October 18. That is 24.9 days later and only 2.2 days before KEV, and the next section looks at this case. Two more notes apply. For CVE-2026-88771 and CVE-2026-102764, the search returned the full 200 posts, so our first-sighting times for them are lower bounds. X search also returns a ranked sample, not every post.

The SSVC result is simpler. None of the 30 entries had exploitation: active before KEV, so in this sample SSVC "active" is a mirror of KEV. For the 12 CVEs with EPSS data on the day before KEV, all 12 scores were below 10%. In this sample, neither field gave an earlier warning than the catalog.

Three comparison cases: NetScaler, Plex2Shell, PHP2Shell

To see whether there is a pattern, we compared three events from the same period. We searched X once for each and lined up their first-party record times, with CVE publication as day 0.

NetScaler: X was early, but the early content was rumor. At 10:54 SGT, we searched NetScaler for September 26 to 28 and got 176 posts. The first was at 15:07 UTC on September 26. A large account said that an unknown, actively exploited NetScaler zero-day made institutions shut down devices. NVD received CVE-2026-88771 at 17:16 on September 27, and X already had 77 posts by then.

Several early posts said that the rumor started in system administrator discussions on Reddit. CISA added the flaw at about 20:16 that day.

In a separate alert, CISA told organizations to check for compromise before they patch. Citrix published its security bulletin the same day. This is the pattern for a big vendor, a zero-day, and an edge device. The victims are large organizations, and the news spreads first among practitioners as "something is wrong". Then the vendor, the CVE, and KEV arrive within one day. X was 26 hours early, but that content was unverified rumor: good enough to start a "check the logs" playbook, not good enough for a conclusion.

Plex2Shell: the vendor said it early, but nobody heard. Plex posted a forum notice at 18:30 UTC on September 1. It said that version 1.43.3 fixed several security issues and that CVEs had been requested. The notice now has 86,684 views. But an X search for plex "security update" from September 1 to 22 found only 1 post.

The CVEs (such as CVE-2026-96652) came out on September 23. The advisory from ACN (Italy's national cybersecurity agency) shows modest scores for each CVE, such as 4.3 and 6.5 (CVSS 3.1). So few people paid attention.

The turn came on October 16, when a researcher published a full analysis of how the 4 flaws chain together. On October 17, another researcher's honeypot recorded exploitation (their blog). The first X post with "Plex2Shell" came at 15:59 on October 18, and CISA added the CVEs on October 20. The pattern: the combined risk of low-score flaws became visible only after a public analysis, and the first public signal was the vendor's own notice. Your watch must read phrases such as "important security update, details to follow". The victim report on Reddit (r/unRAID, 109 comments) appeared on October 21, after KEV.

PHP2Shell: the most attention on X, and still not in KEV. On October 20, the PHP team announced fixes for two critical flaws. The first X post with CVE-2026-109618 came at 18:56 UTC on October 20, about 19 hours before the fix and the CVE (13:48 UTC on October 21, according to CVE.org). Our one search already had 68 posts before the embargo ended at 14:00 on October 21. AWS threat intelligence said in a blog post that its honeypot network saw exploitation attempts on October 17, 4 days before disclosure. The EU agency CERT-EU recorded the event in its advisory.

But when we read the KEV catalog on October 26, it was still at version 2026.10.23 and did not include these IDs. Our search at 10:52 SGT returned the full 200 posts for October 20 to 23, and again the upper date limit was not strict. This case shows that social attention and KEV listing are not linked. KEV needs reliable evidence of exploitation in the wild, and attempts against honeypots may not be enough. For a flaw like PHP2Shell, do not wait for KEV; schedule the fix from your own exposure.

If you put the four cases side by side, the conclusion is not "social platforms are useless". The first public signal appears where the first victims talk. Small self-hosted organizations go to project issue trackers and user forums. Practitioners at large organizations ask each other on social platforms. Vendors give quiet warnings in forums and release notes, and researchers publish in blogs and repositories. A subscription by CVE ID covers only what comes after all of these.

From signal to response: a process that runs once a day

Station 1 is to watch the sources. Your list is not a list of CVE IDs but of the component names that you run, such as richdocumentscode, Plex Media Server, or NetScaler. Each component has three kinds of sources. The first is the project issue tracker and releases (GitHub has a free API for new issues and releases). The second is the vendor forum or security notice page (many forums run on Discourse, which returns JSON), and the third is keyword search on a few social platforms. The KEV JSON and the CVE description are for confirmation and deadlines, not the start line.

In this case, a daily reader of the richdocumentscode issue tracker would have seen "Hack" in an issue title on September 11. That is a month before any subscription by ID. The cost of that reader is one free API call per component per day. The value is the 32.5 days.

Station 2 is to keep the evidence. Save each raw response without edits, with the request parameters, the UTC time, and a file hash. There are two reasons. First, you must be able to answer "when did we know?" later, in the forensic triage that BOD 26-04 asks for and in incident reports. Second, platform content changes: posts get deleted, comments get edited, and summaries have errors. We found the Censys date mismatch only because we went back to the saved issue text.

Station 3 is to match assets. Match your inventory by component name, not by CVE ID, because the Patchless Window median in August was 39.2 days without an ID. The match must include the deployment type. This flaw affects only the built-in CODE app, and standalone Collabora is safe. A match on "do we use Collabora?" gives many false alarms. Worse, it can hide the one server that is really affected among them.

Station 4 is to remove noise. Label each item with the 6 classes from Test 3. Reposts, bots, promotion, and attack-tip posts stay out of the response queue, but they stay in the archive for later checks. In this test, 93.4% of an X search by ID got removed, and 100% of the pre-CVE product-name results got removed. Your rules must also cover word collisions across languages (the Italian "collabora"), account farms (8 accounts, 2 seconds), and "free self-test" links in forums.

Station 5 is to respond. The Collabora advisory says to upgrade to 26.4.303 or remove the app, because disabling it is not enough. If you run an end-of-life Nextcloud 29 or older, upgrade Nextcloud or remove the app.

Post 4 in the Nextcloud forum gave a practical check: after the upgrade, the Nextcloud integrity check reported an "extra file" in the app folder. Italy's CSIRT mentioned web shell installation and credential theft. So for any instance exposed after September 10, we suggest three more actions. Run the integrity check, review the access logs, and rotate the passwords that the web server can read.

We describe only these defensive actions, not what the attack requests look like. The integrity check matters because a patch does not remove files that an attacker already placed. A patched server can still have a back door. That is why the KEV entry asks for forensic triage in addition to the fix.

Station 6 is to close the case. Each case must answer four questions: who handled it, when, on which evidence (a pointer to the raw response in the archive), and what they did. After KEV adds the flaw, compare its due date with your close time. The table below shows the minimum record fields that we suggest, and we used each of them in this test.

The cost: 50 components for one month

At 10:13 SGT on October 26, we read the capability catalog, and the pricing page is the reference. twitter/search, reddit/search, youtube/search, linkedin/search, and threads/search each cost $0.000556 per request. weibo/search costs $0.000806 per request. You pay per request, not per result. We also ran 3 EveryInfra searches at the quick depth ($0.000694 each) on the web and forums for posts before the CVE; all 3 returned 0 results.

Take a small team with 50 internet-facing components and one X search and one Reddit search per component per day. That is 100 requests × $0.000556 = $0.0556 per day, or $1.668 for 30 days. The GitHub issues API, Discourse forums, NVD, CVE.org, KEV, and EPSS are free public APIs, so they are not in this cost.

Empty results and failures are not billed. Of our 60 requests, 6 hit the rate limit (status 429), 1 had a wrong parameter (status 422), and 1 came back empty. None of these 8 were billed. We were billed for 52 requests ($0.029576), and the hero image and one illustration cost another $0.06.

Should you run the loop every hour? With the same 50 components, an hourly loop is 2,400 requests per day, or $1.3344 per day and about $40.03 per month. That is 24 times the daily cost, and it moves a sighting earlier by less than one day. In this case, the first signal came 32.5 days before the CVE, so the difference between daily and hourly does not matter at that scale. An hourly watch fits edge-device zero-days like NetScaler, where the CVE and KEV arrive within one day. That list is usually short, so keep it separate and keep the full list daily.

Get the same data with code or an AI client

One curl request that searches X by ID (the key is a placeholder):

curl -s https://api.everyinfra.com/api/v1/social \
  -H "Authorization: Bearer <API Key>" \
  -H "Content-Type: application/json" \
  -d '{"platform":"twitter","action":"search","params":{"keyword":"CVE-2026-110447","sort":"latest","limit":200}}'

We checked each response field that this article uses against the response_fields of twitter/search in the catalog.

For Reddit, use reddit/search with the keyword and sort parameters (newest, relevance, and others). The fields that you will use most are community, comment_count, and posted_at. Its time range is always the last month. Archive the results at the time if you need more than 30 days of history.

To run the same searches from Claude Code, get a key from the quickstart and add the remote MCP server:

claude mcp add --transport http everyinfra https://api.everyinfra.com/mcp \
  --header 'Authorization: Bearer ${EVERYINFRA_API_KEY}'

Then you can give one instruction: "Use everyinfra_call_api to search X for richdocumentscode and for CVE-2026-110447, and split the posts at 2026-10-14 02:27 UTC." You can then ask it to list institutional accounts apart from personal accounts. The answer uses the same posted_at and author_username fields as the table above.

Here are the errors and billing results that we saw in this test. When we set Reddit's sort to oldest, which does not exist, the response was 422 invalid_value. The error listed all allowed values and said "Nothing was charged". When other requests on the same test key used up the limit of 10 per minute, the response was 429 rate_limited with a retry_after value. That was not billed either, and all retries after retry_after plus 10 seconds succeeded.

A synchronous empty result returns 200 with count 0 and billing.reason set to empty_result_refunded, and it is not billed. For line-by-line reconciliation, see failure refunds and reconciliation. When an X search returns the full limit, the earliest posts may be cut off, and the response does not show an error. Compare count with the limit yourself.

Changes in the last 60 days, and related research

October 23, 2026: CISA added CVE-2026-110447 with a three-day deadline and forensic triage. See the CISA alert. For you, the forensicTriage: Yes field in a KEV entry deserves its own rule. It means "after you patch, check whether you were compromised".

October 21, 2026: PHP2Shell became public, and AWS said exploitation started 4 days earlier. See the comparison cases above. For you, count back from the earliest known exploitation when you investigate. Do not count forward from the advisory date.

October 20, 2026: CISA added six flaws at once, and four of them were Plex2Shell. For you, low-score flaws can reach KEV when they chain together. A filter on single CVSS scores misses them.

October 14, 2026: Collabora blamed the CVE request queue and applied to become a CNA. For you, IDs will come faster when open source projects become CNAs. Until then, a subscription by ID can be a month late.

October 2026: Second Security published the Patchless Window study. In August, the median time from a public fix to a public CVE was 39.2 days. For you, watch open source components through their commits, releases, and issues, and do not wait for the ID.

September 25, 2026: an arXiv paper proposed GPM, a priority metric from exploit repository stars, forks, and users on GitHub (arXiv 2609.31004). The paper says that GPM was integrated into EPSS version 5. For you, public repository activity is now part of formal scoring. But our signal was a victim report in an issue tracker, not exploit code, so this metric does not cover it.

August 19, 2026: a study measured a deployed threat knowledge graph against 10,000 threat-related social posts (Information journal). The graph already held 96% of the actionable vulnerabilities in the posts and reported them at least as quickly. Social media led only in early warning of active exploitation. For you, the study agrees with our result: the value of social data is in a few victim reports and rumors, not in CVE coverage.

August 2026: the STINER study used alerts on X for a European threat picture (arXiv 2608.14418). It found that attacks in different countries have very different visibility on X. For readers, language and region are a fixed variable in social monitoring: in this case, one Japanese post was the only firsthand report on X before KEV. As method background, a 2015 USENIX Security paper already tried to use Twitter posts to predict real-world exploits.

Limits of this article

First, there is only one main case, and we searched each comparison case only once. We have no control group of flaws that were not exploited, so we cannot calculate a false alarm rate. We also cannot say that every "we were hacked" issue means a real flaw. The issue signal was credible here because it had logs, several people saw the same thing, and a maintainer replied within 3 days. Other issues may not have all three.

Second, X search returns a ranked sample. Our ID search returned 106 posts and did not reach the limit, but we cannot prove that X has no earlier posts. The until date limit was not strict in any of our 4 requests that used it, so we filtered on posted_at. Reddit search covers only the last month, so we could not check Reddit for September 10 to 25. A general web search for reddit.com before October 14 returned only old setup questions, with no compromise reports.

Third, the noise was labeled once with a rule written in advance, and there was no second labeler. The line between "signal" and "repost" has some judgment in it. For example, we counted a post that rewrote the advisory as a checklist as a repost, and another person might count it as a signal.

Fourth, the SSVC and EPSS observations apply to one situation: the description already says the flaw is exploited. Do not extend them to "these fields are always slow". EPSS estimates a probability, and its purpose is not to repeat KEV.

FAQ

What does it mean when CISA adds a flaw to KEV?

It means that CISA has a CVE ID, reliable evidence of exploitation in the wild, and clear remediation guidance. Under BOD 26-04, federal agencies must fix it by the due date in the entry, which was three days plus forensic triage in this case. KEV is always later than the CVE. Here it came 9.7 days after the CVE and 42.2 days after the first public report. (From the search suggestion "cisa kev meaning".)

EPSS vs. CISA KEV: which one should I use to prioritize?

They answer different questions. KEV says that exploitation was confirmed, and EPSS estimates the probability of observed exploitation in the next 30 days. In this case, EPSS stayed at 1.2% for the 10 days before KEV. For the 12 KEV CVEs with data in our sample, every EPSS score on the day before KEV was below 10%. Use both to sort, and add a text rule for "exploited in the wild". (From the search suggestion "epss vs cisa kev".)

How do I fix the Nextcloud Collabora vulnerability?

Upgrade the "Collabora Online - Built-in CODE Server" app to 26.4.303 or remove it, because disabling it is not enough. If you run Nextcloud 29 or older, upgrade Nextcloud or remove the app. Standalone Collabora servers are not affected. If your instance was exposed, also run the integrity check, review logs, and rotate credentials. (From the search suggestion "nextcloud collabora vulnerability fix".)

Related reading

• Platform pages: X (Twitter) Scraper API, Reddit Scraper API, Weibo Scraper API
• Capability pages: X Search, Reddit Search, YouTube Search, LinkedIn Search, Threads Search, Weibo Search
• Same series: Vulnerability intelligence as a product, Pump-and-dump social signals, Social data as a research sample

References

1. CollaboraOnline/richdocumentscode, GitHub issue #354 "Security issue - Hack", September 11, 2026, https://github.com/CollaboraOnline/richdocumentscode/issues/354
2. CollaboraOnline/richdocumentscode, release 26.4.303, September 11, 2026, https://github.com/CollaboraOnline/richdocumentscode/releases/tag/26.4.303
3. GitHub, REST API endpoints for issues, accessed October 26, 2026, https://docs.github.com/en/rest/issues/issues
4. Nextcloud community forum, "To Collabora Built-in User: Update ASAP", October 3, 2026, https://help.nextcloud.com/t/to-collabora-built-in-user-update-asap/250516
5. Discourse, API documentation, accessed October 26, 2026, https://docs.discourse.org/
6. CVE Program, CVE-2026-110447 record, October 14, 2026, https://www.cve.org/CVERecord?id=CVE-2026-110447
7. CVE Services API, CVE-2026-110447 record metadata, accessed October 26, 2026, https://cveawg.mitre.org/api/cve/CVE-2026-110447
8. NIST NVD, CVE-2026-110447 detail, published October 14, 2026, modified October 24, 2026, https://nvd.nist.gov/vuln/detail/CVE-2026-110447
9. NIST NVD, CVE Change History API, accessed October 26, 2026, https://nvd.nist.gov/developers/vulnerability-change-history
10. Collabora Online, security advisory GHSA-g3vx-3m76-fghh, October 14, 2026, https://github.com/CollaboraOnline/online/security/advisories/GHSA-g3vx-3m76-fghh
11. Collabora Online, "Stay Safe: Upgrade Everything Regularly", October 14, 2026, https://www.collaboraonline.com/blog/stay-safe-upgrade-everything-regularly/
12. Censys, "Oct 16 Advisory: Collabora Online Built-in CODE Server OS Command Injection", October 16, 2026, https://censys.com/advisory/cve-2026-110447/
13. CISA, Known Exploited Vulnerabilities Catalog, accessed October 26, 2026, https://www.cisa.gov/known-exploited-vulnerabilities-catalog
14. CISA, KEV JSON feed (version 2026.10.23), accessed October 26, 2026, https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json
15. CISA, "Reducing the Significant Risk of Known Exploited Vulnerabilities" (KEV criteria), accessed October 26, 2026, https://www.cisa.gov/known-exploited-vulnerabilities
16. Second Security, "The Patchless Window", October 2026, https://thepatchlesswindow.com/
17. BleepingComputer, "Hackers exploit Collabora RCE flaw to backdoor Nextcloud servers", October 15, 2026, https://www.bleepingcomputer.com/news/security/hackers-exploit-collabora-rce-flaw-to-backdoor-nextcloud-servers/
18. NIST, "NIST Updates NVD Operations to Address Record CVE Growth", April 15, 2026, https://www.nist.gov/news-events/news/2026/04/nist-updates-nvd-operations-address-record-cve-growth
19. Hacker News, Algolia search API, accessed October 26, 2026, https://hn.algolia.com/api
20. Hacker News, "Hackers exploit Collabora RCE flaw to backdoor Nextcloud servers" link post, October 15, 2026, https://news.ycombinator.com/item?id=50111052
21. Reddit r/NextCloud, administrator report "Nextcloud compromised via the built-in Collabora app", October 22, 2026, https://www.reddit.com/r/NextCloud/comments/1xcsjlx/nextcloud_compromised_via_the_builtin_collabora/
22. cisagov, Vulnrichment repository, accessed October 26, 2026, https://github.com/cisagov/vulnrichment
23. FIRST, EPSS Frequently Asked Questions, accessed October 26, 2026, https://www.first.org/epss/faq
24. CISA, BOD 26-04: Prioritizing Security Updates Based on Risk, June 10, 2026, https://www.cisa.gov/news-events/directives/bod-26-04-prioritizing-security-updates-based-risk
25. FIRST, EPSS "Get the Data" (including the API), accessed October 26, 2026, https://www.first.org/epss/data
26. CISA, Stakeholder-Specific Vulnerability Categorization (SSVC), accessed October 26, 2026, https://www.cisa.gov/stakeholder-specific-vulnerability-categorization-ssvc
27. CISA, "Critical Zero-Day Vulnerabilities Exploited in Citrix NetScaler ADC, Gateway", September 27, 2026 (updated October 9), https://www.cisa.gov/news-events/alerts/2026/09/27/critical-zero-day-vulnerabilities-exploited-citrix-netscaler-adc-gateway
28. Citrix, security bulletin CTX697096, September 27, 2026, https://support.citrix.com/support-home/kbsearch/article?articleNumber=CTX697096
29. NIST NVD, CVE-2026-88771 detail, September 27, 2026, https://nvd.nist.gov/vuln/detail/CVE-2026-88771
30. Plex forum, "Important Security Update for Plex Media Server v1.43.2 and earlier", September 1, 2026, https://forums.plex.tv/t/important-security-update-for-plex-media-server-v1-43-2-and-earlier/942319
31. Agenzia per la Cybersicurezza Nazionale (ACN), "Plex Media Server: rilevato sfruttamento in rete delle catena di attacco Plex2Shell", October 2026, https://www.acn.gov.it/portale/w/plex-media-server-rilevato-sfruttamento-in-rete-delle-catena-di-attacco-plex2shell
32. boredhackerblog, "Plex vulnerabilities being exploited in the wild to drop a cryptominer", October 17, 2026, https://www.boredhackerblog.info/2026/10/plex-vulnerabilities-being-exploited-in.html
33. CISA, "CISA Adds Six Known Exploited Vulnerabilities to Catalog", October 20, 2026, https://www.cisa.gov/news-events/alerts/2026/10/20/cisa-adds-six-known-exploited-vulnerabilities-catalog
34. NIST NVD, CVE-2026-96652 detail, September 23, 2026, https://nvd.nist.gov/vuln/detail/CVE-2026-96652
35. AWS Security Blog, "Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot", October 21, 2026, https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/
36. CERT-EU, Security Advisory 2026-018 "Critical Vulnerabilities in PHP", October 20, 2026, https://cert.europa.eu/publications/security-advisories/2026-018
37. NIST NVD, CVE-2026-109618 detail, October 21, 2026, https://nvd.nist.gov/vuln/detail/CVE-2026-109618
38. CISA, "CISA Adds One Known Exploited Vulnerability to Catalog" (CVE-2026-110447), October 23, 2026, https://www.cisa.gov/news-events/alerts/2026/10/23/cisa-adds-one-known-exploited-vulnerability-catalog-0
39. Akhoundali et al., "GitHub Engagement Signals for CVE Prioritization: The GitHub Popularity Metric (GPM)", arXiv 2609.31004, September 25, 2026, https://arxiv.org/abs/2609.31004
40. "Time-Series and Social-Media Threat Analytics over a Deployed Cyber-Threat Knowledge Graph", Information 17(8):794, August 19, 2026, https://www.mdpi.com/2078-2489/17/8/794
41. Ech-Chammakhy et al., "STINER: Automated Extraction of Strategic Cyber Threat Intelligence from X", arXiv 2608.14418, August 14, 2026, https://arxiv.org/abs/2608.14418
42. Sabottke, Suciu, Dumitraș, "Vulnerability Disclosure in the Age of Social Media: Exploiting Twitter for Predicting Real-World Exploits", USENIX Security 2015, https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/sabottke
43. X Help Center, "How to use advanced search", accessed October 26, 2026, https://help.x.com/en/using-x/x-advanced-search
44. NIST NVD, CVE API documentation, accessed October 26, 2026, https://nvd.nist.gov/developers/vulnerabilities
45. The Hacker News, "Hackers Backdoor Nextcloud Servers Through Critical Flaw in Collabora’s Built-in CODE App", October 2026, https://thehackernews.com/2026/10/hackers-backdoor-nextcloud-servers.html