Lithuanian company websites in October 2026: WordPress, PHP and DMARC in public data

This is a count, not an audit. On 2026-10-24 we requested the public homepage of each website on our prospect lists once and read the public DNS records of the domain: what anyone with a browser and a DNS lookup can see, nothing behind a login. It is not a random sample of Lithuanian companies.

The hosts are websites tied to a company code on our own outreach lists; we have not analysed the sector or size composition of those lists for this post, so every percentage below describes this sample, not the country.

What we looked at and how

• Population. 932 Lithuanian hosts, each tied to a company code on our outreach lists. 19 were unreachable, 9 disallowed our user agent in robots.txt and were skipped, and 14 answered without a recognisable technology. That leaves 890 sites with at least one technology detected (932 − 19 − 9 − 14 = 890), the denominator for the site-level figures.
• One request per host. A single GET of the public homepage with a named user agent, after reading robots.txt; we recorded response headers, HTML markers (meta generator tag, asset paths) and DNS MX and TXT records. No other path was requested, nothing was tested, no company is named.
• Reading the counts. "WordPress" means its markers were visible in the HTML; a PHP version counts only when the server disclosed it in an X-Powered-By header. The counts are exact for what is publicly visible and lower bounds for what exists.

Content management systems

Six in ten sites run WordPress; the other four named systems together are 50 of 890 (5.6 %). The plugins matter because a WordPress site is updated plugin by plugin, and each one can be left behind. How to check your own site against a plugin advisory is in WordPress plugin vulnerabilities: how to know in an hour.

WordPress branches

The version was publicly visible on 356 of 535 WordPress sites (66.5 %). Our branch tally totals 359 readings, three more than 356; the raw data does not say why, so we report the tally as recorded and compute shares against 359.

For the "current" column we read wordpress.org/news on 2026-10-24: the latest stable release was 7.1.3, a maintenance and security release with 7 security fixes published on 2026-10-06; 7.2 was at Beta 1 (2026-10-20). So 7.1 is the current branch; a visible branch does not show the point release.

So 30 + 113 + 39 + 15 = 197 of 359 readings (54.9 %) are on a branch older than the current one, and 54 (15.0 %) on 5.x or 4.x. From the outside the number shows only the branch, not whether security fixes still arrive. The 179 WordPress sites that hide their version (535 − 356) are not safer for hiding it; they are simply not counted.

PHP branches and support status

A PHP version was disclosed by 124 of 890 sites (13.9 %). Support status is from php.net, read on 2026-10-24: security fixes for 8.2 end on 2026-12-31, for 8.3 on 2027-12-31, for 8.4 on 2028-12-31 and for 8.5 on 2029-12-31. Branch 8.1 reached end of life on 2025-12-31; everything older ended earlier.

The arithmetic: 12 + 5 + 14 + 4 + 4 + 7 = 46 of 124 sites (37.1 %) run a PHP branch that receives no security fixes; 78 (62.9 %) run a supported one. The 30 sites on 8.2 lose security support on 2026-12-31, 68 days after our observation date; if nothing changes, 46 + 30 = 76 of 124 (61.3 %) will be unsupported on 2027-01-01.

That is arithmetic on today's counts, not a forecast. What "end of life" means in practice is in PHP supported versions in 2026.

Email authentication: DMARC and SPF

For email we read only DNS. RFC 7489 defines three policy values: with p=none the domain owner "requests no specific action be taken" on failing mail; with p=quarantine failing mail is to be treated "as suspicious"; with p=reject receivers are asked "to reject email that fails the DMARC mechanism check".

Only quarantine and reject do anything to a forged message that claims to come from your domain.

The arithmetic: 435 + 247 = 682 of 890 domains (76.6 %) have no enforcing policy; 143 + 65 = 208 (23.4 %) do. Of the 455 domains that publish a record (890 − 435), 247 (54.3 %) stopped at p=none, the monitoring stage. SPF is present on 866 of 890 domains (97.3 %), so the gap is not awareness but finishing the job.

The MX records of 378 domains (42.5 %) point to Microsoft 365 and those of 76 (8.5 %) to Google Workspace. Getting from none to reject without losing legitimate mail is in DMARC p=reject for companies.

Three smaller signals

• HSTS (RFC 6797: a site declares itself "accessible only via secure connections"): 201 of 890 sites (22.6 %).
• Cloudflare in front: 190 (21.3 %); that is the network in front, not the software behind it.
• Server header disclosing a version: 66 (7.4 %). Easy to bring to zero.

What it means (vertinimas)

All four tables show one pattern: the first step is widely taken, the last step is not. SPF is on 97 % of domains, DMARC enforcement on 23 %. WordPress is everywhere, the current branch on fewer than half of the visible installations. Supported PHP is on 63 % of disclosing sites today and, on current counts, 39 % from January.

None of this is a verdict on a single company; a site on an old branch may be patched by its host. It shows where the unfinished work is, from public data alone. For companies under the Lithuanian transposition of NIS2, a supervisory authority can read the same signals; see NIS2 in Lithuania: KSIS and what companies must do.

Three actions for this week

1. Ask which PHP branch your site runs, and write the answer down. Your host sees it in the hosting panel in a minute. 8.1 or older is already outside security support; 8.2 needs a plan before 2026-12-31.
2. Read your own DMARC record. Look up the TXT record at _dmarc.yourdomain.lt. No record, or p=none, means a forged message from your domain is not stopped. Move to quarantine, read the reports for a few weeks, then reject.
3. Get the WordPress branch and the plugin list in writing from whoever maintains the site. The current release on 2026-10-24 was 7.1.3. A one-line monthly note ends the guessing.

If you would rather have someone read these public signals every month and say, in plain Lithuanian or English, what changed and what to do first, that is what Northwestern Tideline does. We never go beyond the public homepage and DNS without your written authorisation; write to us and we start with your own domain.

The wider context is in Cybersecurity for companies in the age of AI.