Updates
Only completed engine improvements whose evidence has been verified, with R50 as the starting point. The date on each entry is the day the change was verified — not the day this site published it.
What this ledger counts, and what it does not
These entries are the engine’s own version history: detection rules, data matching, report language and tests. The source is a single evidence-backed history file; entries are not typed by hand. R50 is where this ledger opens, and the R50 date records the day those sources were taken into the engine — it is not a first product launch or a publication day. No estimated date is produced for anything before R50.
Every entry carries four things: the date, the version and title, the effect on you, and the coverage limit of that change. The newest entry sits on top. The date is the day the improvement was verified by local tests and recorded; live publication has to be verified separately, and the two dates need not be the same.
Days that produce no entry
- Days with no change at all.
- Days with research only.
- Days with a test run only.
- Work that is planned, awaiting pilot acceptance, or failed.
- A security advisory or CVE report on its own.
Nor is this page a counter: the engine’s check, layer and operational-feature inventories are separate units, they are never added together, and this ledger produces no new check total. For coverage figures see Capabilities and Score Model.
Boundary
An entry here does not show that the feature runs on your site, or that your site has been audited. The ledger is the engine’s history; it is not a site report or a publication approval.
LAST RECORDED RUN
Last verified research and test status
The values below are taken from the engine’s own status output exactly as recorded in the run of 23 October 2026. Research time and test time are separate fields; neither stands in for the other. The research record published here comes from a manually started run: this section is not evidence of output from the scheduled 12:00 run.
Research record
Last record: . Of 21 required sources, 16 were checked. Five required sources — NVD, CISA KEV, PortSwigger Research, HackerOne public reports and Exploit-DB — could not be reached in that run; being unreachable was recorded as such, and no current coverage is claimed for them.
This record comes from a manually started run (trigger: manual request) and covers the 16–23 October 2026 review window; it is not evidence of output from the scheduled 12:00 run. An unreachable source never produces a “no vulnerabilities” result; it stays visible as missing coverage.
Maintenance tests
Finished: . That run covered report generation, security matching, the maintenance record and run-policy tests.
That run performed no research of its own and changed no public history entry. A passing test on its own produces neither a new product feature nor a new history entry.
Execution mode
The arrangement runs on a local computer; no server is set up. An enabled schedule is not evidence that the work was carried out.
A missed run is not counted as a successful one, and a missing day is not added to the history as an entry.
This page is static and is not a live status indicator: the values belong only to the moment of that run. The engine itself does not treat research or test results older than 48 hours as current and marks them “stale”; if the source files have changed, the test result becomes “source changed”. Current status can only be read by running the command on a local installation.
Verified changes
Newest first. Three status labels are used: BASELINE is the entry where the ledger opens; HISTORICAL RECORD marks entries the source data classifies as historical, with archived evidence — the classification comes from the source even when the version number belongs to the current family, and the page adds no generation reading of its own; VERIFIED marks improvements verified by the current engine tests. The evidence for every entry is kept locally; the paths and digests of those evidence files are not published.
Report accuracy and PDF dependency security update
Fixed a language conversion that blocked native report generation. Reduced false findings in directory-listing and canonical checks while preserving missing evidence as unknown. Updated the PDF dependency to the vendor fix for three advisories. Regression tests and native Word/PDF verification passed. This is the local verification date, not live deployment or site approval.
This entry comes from the engine's own verification run. The fixes belong to the engine's own source; no patch is applied to a customer server, and no live deployment took place in this entry.
Current advisory context and readable score guidance
Added optional KEV/EPSS context for CVE candidates, five Python dependency patches and native report guidance on score bands, meaning and next actions. Comparability, environment context and missing-measurement explanations passed integrated tests. No live website deployment.
KEV is a record that a vulnerability has been exploited in the wild; EPSS is a 30-day probability estimate. Both are optional context, both are off by default, neither replaces CVSS or the report’s core score, and neither is added to that core score. The dependency patches belong to WebTrustEngine’s own runtime; no patch is applied to a customer server. No live-site deployment took place in this entry.
Local preference components and report regression verification
Added consent and reading preference components, offline heatmap and portfolio views, Jira CSV and brand/citation analysis for supplied model answers. Fixed additional report regressions and expanded daily tests, with native Word/PDF verification. No live deployment.
The components are local; they collect no live visitor data and provide no hosted service. Jira CSV is an export, not a live API connection. Brand/citation analysis examines only the model answers handed to it; it does not connect to the model itself. No live installation took place in this entry.
Content policies and evidence-based retesting
Added static content policies, team ownership, fix and regression tracking, CI budgets, a local site portfolio and aggregate customer analytics/heatmap-cell imports. This does not provide live visitor collection or hosted services.
An import is not live data collection and provides no hosted service; it works on aggregate data. Nothing here counts as an installation on customer sites.
Native maintenance tracking and research corroboration
Added evidence-bound local maintenance commands and capability records. Public security research joined the daily source registry, with guards against treating unverified or retracted signals as completed work. No server or dark-web connector was deployed.
No server was deployed and no dark-web connector was set up. Adding a source to the registry does not mean that source is scanned in full every day.
Current security advisories and continuous maintenance
Added NVD/OSV version matching, source age and coverage reporting. Critical PHP advisories and conditional vendor notices are shown separately. Daily research records feed a deduplicated roadmap; only evidence-backed changes enter the public history.
A version match is a candidate finding, not evidence of an exploitable vulnerability on the target. The PHP runtime, the WordPress core and plugins/themes are separate layers; the plugin/theme provider connection is unfinished — an account and key requirement on the provider side remains open work. No zero-day or find-every-vulnerability guarantee is given.
Task-based usability assurance
Added local synthetic task evidence, regression comparisons, optional SafeFix task checks and expiring risk acceptance. Synthetic tasks do not replace real user research.
A synthetic task result does not replace real user research. Automated checks do not satisfy a human accessibility evaluation or any certification.
Browser evidence and product assurance
Expanded browser observations, offline field-data imports, signed decision records and controlled report publication.
Field data is imported; the engine does not produce live field measurement of its own. A signed decision record is an internal record discipline, not an independent certification.
Evidence-linked catalogue and decision reporting
Catalogue records were classified by execution and evidence type, preserving unknown results and traceable report figures.
A catalogue row is neither a feature nor a pass mark. Not having been measured does not mean a score of zero.
R50 baseline recorded
Historical R50 sources were archived separately from the active engine. This is the source import date, not the original product release date.
This date shows when the sources were imported; it is not a first product launch or a live publication day. No estimated entry is produced for anything earlier.
How daily research and maintenance run
Research and maintenance work is scheduled daily at 12:00 Türkiye time. The current arrangement is local: the computer and Codex have to be running. No server is set up, and no 24/7 cloud service has been set up. There is no uninterrupted monitoring either: if the computer is off, that day’s work does not happen, and a missed run is not counted as a successful one. If an urgent advisory appears after 12:00, it is handled in the next local run — this is not a real-time alerting service.
The subject of this maintenance is the engine itself: detection rules, product and version matching, data adapters, report wording and tests. It is not a daily scan of customer sites; no patch is applied automatically to customer servers and nothing is installed in a customer environment. This arrangement is WebTrustEngine’s own local automation.
Which source layers are consulted
- Vendor and advisory data — PHP, WordPress and other vendors, NVD, OSV, GitHub Advisories: product identity, affected and patched versions, fix conditions.
- Coordination and exploitation data — CERT/CC and CISA KEV: independent corroboration and priority based on observed active exploitation.
- First-hand research — research teams’ own technical publications: new bug classes and examples of incomplete patches.
- Publicly disclosed findings — disclosed reports only; a private or redacted report does not count as reviewed.
- Public exploit references — the existence of a PoC and its product/version relationship; no PoC is executed, and its existence is not evidence of an active attack.
- Probability-based priority — EPSS: a dated estimate signal.
In the last recorded run not all of these layers could be checked successfully. NVD and CISA KEV could not be reached; only KEV’s non-required official mirror could be read (the catalogue publication it returned is dated 21 October 2026), and the canonical source’s failure was not relabelled as success. In the first-hand research layer PortSwigger Research could not be read, and the Cisco Talos index was seen only as a cached crawl five days old, with freshness through 23 October unverified.
The publicly disclosed findings and public exploit reference layers had no successful check at all. Which source was readable in which run is put on record, and no coverage is claimed for a source that could not be reached.
Dark-web and closed threat feeds are out of scope: there is no provider, membership or adapter in place, and no such feature is claimed. A source being on the list does not mean all of its content is scanned every day either; the actual access result is recorded in every run.
What a match says, and what it does not
A version match is a candidate finding: it is not evidence that the vulnerability is exploitable on the target. The running version, the distributor’s backported patch and the configuration conditions are verified separately. KEV is a record that a vulnerability has been exploited in the wild; EPSS is a 30-day probability estimate. Both are optional context, neither replaces CVSS or the report’s core score, and neither is added to that core score.
The layers are read separately: the PHP runtime, the WordPress core and plugins/themes are different scopes. A PHP advisory may not be closed by a WordPress update; the right layer has to be patched. No definite match is produced for a component whose identity or version cannot be verified; the missing input is recorded as open work.
Where these queries go
An offline scan uses no network: refreshing the version query is off by default. The KEV/EPSS priority context is a separate option, and it is off by default as well. When the operator explicitly enables one of them, the request goes to the data source rather than to the target site: the component name and version to OSV, the full CPE identifier to NVD, and only public CVE identifiers to FIRST EPSS. Nothing is sent to CISA KEV: the public catalogue is downloaded and matched locally.
No customer source file, target address or password is sent. The requests come out of a hard budget: 20 requests and 120 seconds by default, at most 200 CVEs, and groups of at most 50 identifiers for EPSS. Identifiers beyond those limits stay recorded as not queried; the query, the response, the source address and the retrieval time are recorded.
What is not promised
Finding every vulnerability, covering unknown infrastructure, a zero-day guarantee, covering all WordPress plugins and themes, uninterrupted monitoring and automatic patching: none of these exists in this product.
For the whole security boundary see Security Boundary, and for what the score bands mean see Score Model.
TEN QUESTIONS
About updates and daily maintenance
Q: Does a WordPress update close a new PHP vulnerability?
A: Not always. The layer the advisory affects — the PHP runtime, the WordPress core or a plugin — is assessed separately, and the right layer has to be patched.
Q: Are all vulnerabilities in every stack found?
A: No. Coverage is limited to components whose identity and version can be verified, and to the data provider’s own scope. For concealed versions, bespoke software and vulnerabilities not yet known, there is no completeness guarantee.
Q: Are WordPress plugins and themes covered too?
A: An inventory can be taken, but any scope whose current provider connection is unfinished stays unverified. Core version matching runs separately.
Q: Is a match a definitely exploitable vulnerability?
A: No. The running version, the distributor’s backported patch and the configuration conditions are verified separately.
Q: What happens if a source service cannot be reached?
A: The outage or the stale data is recorded explicitly. Failing to obtain information never produces a “no vulnerabilities” result.
Q: Is a new feature added every day?
A: No. Daily maintenance may produce no new product feature at all. This page holds only completed, verified changes.
Q: Does it run while the computer is off?
A: The current local arrangement does not. Server and cloud execution are out of scope for now, and a missed run is not counted as a successful one.
Q: Is a patch installed automatically on a customer site?
A: No. This maintenance task improves WebTrustEngine’s own detection rules and engine; it installs no patch in a customer environment.
Q: Is the date in the history the live publication date?
A: Unless stated otherwise it is the day the product change was verified. Live publication has to be verified separately.
Q: How is an incorrect or retracted advisory handled?
A: The source is re-examined and the affected rule and wording are corrected. Earlier evidence is not deleted and history is not changed silently.
For the wider question set see the FAQ.
Seeing what a change means for your own site takes an evidenced snapshot of it.
Prepare an audit request