CoreFiles: Every Joomla and WordPress Core File, Free to Check

You are cleaning up a hacked site and there is an index.php in the root that looks right. It has the right name and it is in the right place, and you still cannot say whether it is the file Joomla or WordPress released. CoreFiles, a new free service from mySites.guru, answers that in a browser by checking Joomla and WordPress core files against the original release.

Until now the only sure way to prove it was to work out the exact release the site runs, find that zip, download it, unpack it and diff the two files by hand. That is a lot of work for one file, and a hacked site rarely has just one file in doubt.

CoreFiles holds the original core files from over 2,000 releases, byte for byte, read from the official release zips. You can check a hash against all of them, compare two releases, or link straight to any file. There is no account to create and nothing to install.

If your sites are already connected to mySites.guru, none of this is a manual job: every audit runs the comparison for you, as described under Checking Every Site You Manage.

What Is in CoreFiles

CoreFiles holds the files from each Joomla and WordPress release it has been able to fetch, pre-releases included. On 14 November 2026 that was 2,040 releases.

The rest are pre-releases: 202 release candidates, 67 betas and 63 alphas for Joomla, and 254 release candidates and 200 betas for WordPress. Together the releases list 6,924,965 files, which come to 284,729 unique ones, because the same file is included unchanged in release after release. Each unique file is stored once, however many releases included it, so the whole collection takes 2.43 GB. The release zips add up to 30.2 GB, and 82.9 GB unpacked. It replaces an older service from 2018 that kept 22.6 GB of zips.

Nothing in it is typed in or rebuilt by us. Joomla’s releases are read from the official zips behind Joomla’s downloads, and WordPress’s from the WordPress release archive. A download is only stored once it matches the checksum the project publishes: the sha256 from Joomla’s signatures API, or the .sha1 file for a WordPress zip. For stable WordPress releases every file is also compared with the WordPress.org checksums API.

New releases are fetched every hour. A regular verify reads all the stored files back against their hashes, and the last full one, on 14 November 2026, found no problems. CoreFiles is run by mySites.guru and is not an official Joomla or WordPress service, which its home page says too.

Is This File Really Part of Joomla or WordPress?

Paste the file’s md5 or sha256 into CoreFiles Lookup and you get a straight answer. Either it lists every release and path that included exactly those bytes, or it tells you that no Joomla or WordPress release has ever included that file.

Getting the hash takes one command on the server, or on your own machine if you have downloaded the file:

# Linux
md5sum index.php

# macOS
md5 index.php

A match reads like this one, for the index.php from Joomla 6.2.0: “This is Joomla’s own index.php. Byte for byte the file shipped in 7 releases, 6.2.0-alpha3 to 6.2.0. On a site running one of those versions, this file has not been touched.” Under it is every release and path with those bytes, along with the file’s size, md5, sha1 and sha256.

Read the list of releases, not only the first line. A file that matches an original from a different version to the one the site runs is still an original, but it is not the file that version should have.

When nothing matches, Lookup says “No Joomla or WordPress release has a file with md5” followed by your hash, and then: “If it came from a site’s core folders, it was added or changed after install. Compare it with the original using the release and path it claims to be.” That is the right next step. A no-match does not tell you who changed the file, and a developer who edited core by hand years ago produces the same answer as an attacker. Open the original for that release and path, and read the difference.

Compare Two Releases, or One File’s History

CoreFiles Compare lists every file added, removed or changed between two releases of the same platform. Pick From and To, and any one file in the list opens as a red and green line diff. The comparison of WordPress 7.1.3 with 7.1.4 is an example.

The URLs are predictable, so you can write one without visiting the page first:

https://corefiles.mysites.guru/diff/{platform}/{from}/{to}
https://corefiles.mysites.guru/diff/{platform}/{from}/{to}/{path}

It is the quickest way to see what a security release changed before you roll it out to client sites. The release notes say what the project wants you to know, and the list of changed files shows what was done.

History answers a different question: when did this one file last change? It lists the releases where a file’s content changed, at /history/{platform}/{path}. Joomla’s index.php has had 51 different versions since Joomla 1.0.3, and WordPress’s wp-load.php has had 37 since 2.6-beta1. If the copy on a site matches none of them, it is not an old version left behind by an upgrade.

Link to Any File, in Any Release

Every file in every stored release has its own URL, and they all end the same way: the platform, the version, then the path. The first part of the URL chooses what you get back.

So the administrator index.php from Joomla 6.2.0 can be fetched, read or hashed like this:

https://corefiles.mysites.guru/raw/joomla/6.2.0/administrator/index.php
https://corefiles.mysites.guru/pretty/joomla/6.2.0/administrator/index.php
https://corefiles.mysites.guru/stat/joomla/6.2.0/administrator/index.php
https://corefiles.mysites.guru/md5/joomla/6.2.0/administrator/index.php
https://corefiles.mysites.guru/folder/joomla/6.2.0/administrator/

Two more are there for scripts. /hashes/{platform}/{version}/plain returns the md5 list for a whole release, one file per line as the path, a tab and the md5. /releases.json returns one object per stored release.

A release never changes once it is out, so file responses are cached for a year. If you ask for a release that is not stored yet, the 404 names the nearest stored versions and the missing one is queued for fetching within the minute.

They are handy in support replies, too: telling a customer “line 12 of your file is not in the original” is far more convincing with a link to line 12 of the original.

What Do Joomla and WordPress Publish Themselves?

WordPress publishes an md5 for each core file but not the files, and Joomla publishes hashes for whole packages only. On both platforms, getting one original file to compare against means downloading the whole release zip.

WordPress does the most here. The checksums API at api.wordpress.org/core/checksums/1.0/, which core reads through get_core_checksums(), returns an md5 per file for a version and locale. The hashes differ per locale, because the German package has liesmich.html where the English one has readme.html. WP-CLI’s wp core verify-checksums checks a site against them and reports “File doesn’t verify against checksum”, then leaves you with nothing to restore from.

Joomla’s update feed has sha256, sha384 and sha512 hashes for each package, and since Joomla 5.1 core updates use TUF signed metadata. The “File Checksum Failed” error in Joomla’s updater is about the update zip it has just downloaded and says nothing about the files already on your site. Joomla has no per-file hash list and no built-in core file integrity check, although requests for one have sat in its tracker since 2014 and 2017. A GitHub tag does not help much either, because for Joomla it is the source tree and not the built package.

My view after more than 15 years of cleaning these sites up: both projects put their effort into proving the download is untampered at the moment you install it. That is worth having, but a hacked site asks a different question: what is on the disk today? WordPress gets part of the way with a hash to check against. Neither gives you the file to read or put back.

Checking Every Site You Manage

CoreFiles is the manual tool. On a site connected to mySites.guru, every audit compares each core file with the original for the exact version the site runs, so a changed file shows up without you hashing anything. On Joomla the audit check is titled “Changes To Core Joomla Files Should Be Avoided”.

Investigate then shows the changed file beside the original, line by line. That is how an injection like the fake Cloudflare captcha in a WordPress core functions.php stands out in seconds, where reading the file cold would not show it.

When the change should not be there, the “Revert to the core file” button puts the original back. It is also in the row menu beside “Compare with the core file”. It asks “Revert this file?” first and warns that the file will be replaced with the original from the CMS release your site runs, and that your changes to it are lost. The connectors use the same store to restore core files that have gone missing. Reverting is one step of fixing a hacked Joomla or WordPress site, not the whole job.

The per-version file list is used from the other direction as well. The Impostor Files check looks for files sitting in core folders that core never included, which is where backdoors like to live. Together the two checks cover core from both sides, and the audit goes on to find hacked files and backdoors in the rest of the site.

So if you have one suspicious file in front of you today, paste its hash into CoreFiles and check it against the original Joomla or WordPress core file. It is free. If you have a few hundred sites, let the audit do it on all of them.

Clean a Hacked Site with Suspect Content and Hacked FilesUse mySites.guru's Suspect Content and Hacked Files tools to find, confirm, and clean backdoors on a hacked Joomla or WordPress site, step by step.Read the full post