Support

What you see here is the Akeeba Backup JSON API V2 endpoint. See https://www.akeeba.com/documentation/json-api/apiv2.html for detailed information.

You always get an HTTP 200 OK response. The actual status of the response is encoded in the status property. An unauthorized request gets a "status": 503 in the JSON body.

To illustrate this, let me run the exact same request on my test site with curl -i and show you the output (only the cookie names and contents have been changed):

HTTP/2 200
x-powered-by: PHP/8.5.7
cache-control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
pragma: no-cache
expires: Wed, 17 Aug 2005 00:00:00 GMT
set-cookie: 0123456789abcdef0123456789abcdef=0123456789abcdef0123456789abcdef; path=/; secure; HttpOnly
set-cookie: abcdef0123456789abcdef0123456789=en-GB; expires=Tue, 06 Jul 2027 01:41:03 GMT; Max-Age=31536000; path=/; secure; HttpOnly
referrer-policy:
last-modified: Mon, 06 Jul 2026 01:41:03 GMT
content-type: application/json; charset=utf-8
date: Mon, 06 Jul 2026 01:41:03 GMT
server: Apache/2.4.68 (Unix) OpenSSL/3.6.2

{
    "status": 503,
    "data": "Access denied"
}

Just because something responds with 200 OK does not mean your site is compromised. It only means that the HTTP status was 200 OK. Instead of making assumptions and allegations, read the documentation. I did not write it for myself. I know how my JSON API works and even have a public client library for it. I could have left it at that. I wrote the full documentation of the API so y'all can understand the traffic you see on your site and evaluate it, as well as anyone wishing to implement the API in a language other than PHP not having to reverse engineer the API behavior from my code.

I am not entirely convinced for a few reasons (also noting I do not have the entire log file).

The size alone does not tell me anything. There might be other output from PHP or a third party plugin before our code runs.

A backup would not be just two requests with the same output size three hours apart. Backups are taken in small steps. There would be several closely spaced requests with varying lengths.

Taking a backup would be visible. There would've been a backup record in Akeeba Backup. Even if the record was deleted, you'd observe a gap in the numbering when taking a new backup.

Just taking the backup makes no sense without having modified the profile to upload it to an attacker-controlled location or downloading it; that's the exfiltration part.

What I am saying is that the response size means pretty much nothing by itself. You need to know what your server returns when you reproduce an unauthenticated request to that URL. Framing this as "is this a vulnerability in Akeeba Backup" when you don't even know what information is returned is rather nonsensical and a bit of a rage-bait, don't you think?

Regarding SP Page Builder, it was one of the extensions suffering a zero-day the past few weeks. JCE and iCAgenda also did, all allowing arbitrary file uploads into predictable paths. That was definitely how you got hacked. Whether Akeeba Backup was used to exfiltrate data is questionable, as I am not sure a backup was taken. I would also note that even if you don't have Akeeba Backup installed, data exfiltration is rather trivial with OS tools such as tar and mysqldump. If anything, dropping a web shell allows an attacker to run a reverse SSH tunnel. In turn, this makes the whole exfiltration faster, less noisy on the logs, and fairly concealable at the very least as far as Bash history goes.

Peter, I think there was a bit of miscommunication here.

I am not angry at you, and I personally don't think you intended to frame this as an Akeeba Backup issue. I just wanted to remind you that this being a public ticket, other people would think that when reading “if this specific log signature matches a known older vulnerability patch, or if it indicates that our Akeeba "Secret Word" configuration was compromised/bypassed internally by an auxiliary script”. I understand that "internally" here means "by code maliciously put on our site by the attacker". Most people would understand this as "by Akeeba Backup's own code".

Basically, I am asking you to be a bit more careful in your wording in public tickets. You are not communicating just to me, you are communicating to the average thoroughly non-technical person on the Internet. Same applies to me when replying back to you. 

I am also aware that you are not the developer. I think I didn't put my technical information in good enough context. I am not giving this technical information to you for you. I expect you to pass them on to your systems administrators and developers – or your AI assistant acting as such. Reading between the lines, it sounded like you were suspecting data exfiltration by means of a backup taken abusively by the attacker, but you had no way to check for it. I gave you the technical bits your devs can use to answer that question with a very high degree of confidence. I also expect that some poor soul reading this three years later having a similar question will go "a ha, so that's how you check if a backup was taken remotely". Again, I am talking to you, but communicating to a wider audience.

I hope that puts my replies into perspective and makes it abundantly clear I am not angry or even annoyed at you. If anything, I empathize. You're by far not the only person hit by one of these zero days. I would recommend taking a look at the news section of our site where I explain both how to clean a hacked site, and what to do to prevent the hack (as well as how the hack could've been neutered by using some common Admin Tools options). Feedback on that is always appreciated.