Looking at the metadata for the relevant endpoints, it looks like an Manjaro maintained bucket at Amazon.
One can only speculate why it has not been updated.
Summary
10:05:44 ○ [fh@tiger] ~
$ curl -I https://aur.manjaro.org/packages-meta-ext-v1.json.gz
HTTP/2 200
date: Thu, 25 Jun 2026 08:28:12 GMT
content-type: application/gzip
content-length: 13502897
last-modified: Mon, 15 Jun 2026 03:24:03 GMT
x-rgw-object-type: Normal
etag: "2e4f56fde3cb277739f614bd4966c310"
x-amz-meta-s3cmd-attrs: atime:1781493842/ctime:1781493842/gid:0/gname:root/md5:2e4f56fde3cb277739f614bd4966c310/mode:33188/mtime:1781493628/uid:0/uname:root
x-amz-storage-class: STANDARD
x-amz-request-id: tx00000598382f12c06d0b9-006a3ce61d-c807316-prg
x-77-nzt: lGWifF1WdHmBomkCVhtsY3v89qW8GZtg4LI84ICn5NM5OYbb9Ui8fvMsq5VwYKruTO9KWQOmkWkkg6+Fuw
x-77-nzt-ray: c1fb98194c8163e49ce63c6a8a68d933
x-77-cache: HIT
x-77-age: 51
server: CDN77-Turbo
x-77-pop: copenhagenDK
accept-ranges: bytes
10:28:12 ○ [fh@tiger] ~
$ curl -I https://aur.archlinux.org/packages-meta-ext-v1.json.gz
HTTP/2 200
server: nginx
date: Thu, 25 Jun 2026 08:28:21 GMT
content-type: application/gzip
content-length: 13547702
accept-ranges: bytes
cache-control: max-age=300
etag: "6a3ce578-ceb8b6"
expires: Thu, 25 Jun 2026 08:33:21 GMT
last-modified: Thu, 25 Jun 2026 08:23:20 GMT
strict-transport-security: max-age=31536000; includeSubdomains; preload
just speculation
It is possible that the AUR webteam took the metadta endpoint offline to prevent the endpoint from spreading the git repositories of the malware from the metadata.
If that is so - then the Manjaro service providing updates to the bucket may lack proper error handling and that has caused the service to fail and it will only resume when the service has been restarted.