Security notice: unauthorized access to our Git server

Published: Nov 12, 2026

Affects: Ashigaru mobile v1.0.0 and later. PayNym and Soroban URL replacement could only have occurred on v1.1.0 or later.

Bitcoin at risk: none identified.

Action required: check your PayNym and Soroban functionality URLs in Ashigaru mobile. See "What you should do" below.

App fix: in development, not yet released. See "What we are changing" below.

Overview

On Nov 5, 2026 (~06:29 UTC) an unauthorized party obtained command execution on the server which hosts the Ashigaru source code and release files. While they were there, they modified ashigaru_mobile_latest.txt, the PGP signed manifest which Ashigaru mobile uses to check for new versions and to update its PayNym and Soroban Tor URLs.

They did not forge a signature, and they did not obtain any signing key. They added six lines to the part of the file which a PGP signature does not cover.

In testing we have confirmed that Ashigaru mobile accepts version numbers and URLs from that unsigned part, and applies them. We have restored the genuine manifest and rebuilt the server.

The parser behavior itself is not yet fixed in a new release of Ashigaru mobile. A corrected build is currently in development and will be released, and we will publish a further notice when it is available to download and install. Until then, the server-side work described below is what stands between the Ashigaru mobile app and a modified manifest, and the checks in "What you should do" still apply to every current build.

What happened

Our Git server was running an outdated release of our Git software, on an operating system which was also behind on its updates. That software was exposed to publicly disclosed vulnerabilities which allow an unauthenticated attacker to run commands on the server and to read files which the service can access. Those issues had been fixed upstream months earlier. We had not applied the available patches/updates.

We have not finished establishing which specific vulnerability was exploited, and we will not claim it was a particular one until we can show it. What we can say is that we were behind on both the Git application and host software version, that the updates were available, and we were not monitoring for new releases. That is the cause, and it is ours.

The container was running from a moving tag which we did not re-pull since June 2026. That detail is embarrassing rather than decisive, because it made an old image look current, but the real problem is that we had no routine for tracking security releases upstream. We have one now.

Once on the server, the attacker:

• modified the signed release manifest used by Ashigaru mobile;
• searched the host for Android signing keystores and PGP private keys, a search script which returned an empty result at 07:32 UTC;
• read our APK build documentation;
• wrote commits directly into the repository on disk, requiring no Git identity and no Gitea account due to local access;
• created an account and API tokens to keep working;
• left a persistence mechanism on the host (which we later identified and removed).

All of it ended when the service was taken offline.

We took the service offline at 09:16 UTC, before the report described below reached us at 09:48 UTC. We observed access to repository pages beginning to fail at around 07:55 and powered the server off as a precaution, without yet understanding the cause. The report shared with us did not trigger our response. It told us what we had been responding to, and it did so with a precision we had not reached ourselves.

An anonymous user found this before we did

We are crediting this report to an anonymous user who was reviewing v1.2.0 before installing it, and noticed five unsigned commits on the main branch.

They read the v1.2.0 source code carefully rather than guessing. They predicted the exact mechanism, that the signature was checked against the signed text while the values were read from the whole message, with substringBetween taking the first match, so the unsigned header would win. They supplied SHA-256 hashes for both the genuine and the modified file. They wrote to us privately rather than opening a public issue, and they were careful to state which parts they had not tested and could not know.

Every technical claim in that report has since been confirmed, including by our internal tests. Our reply asked how the reporter wished to be credited. This is published anonymously, at their request.

Timeline

All times UTC.

From the commit at 06:36 to the service going down at 09:16 is two hours and forty minutes, and that is the full window in which the modified file could have been served.

What was not compromised

• Our PGP release signing key. It has never been on this server. Our public key is published on Keybase only, deliberately not on this website and not on the Git server, so that compromising the Git host cannot influence what a user trusts. The signature on the genuine manifest remains valid.
• Our Android APK signing keystore. Not stored on this server, and not found by the attacker's search.
• Any released APK, binary or signature file. None were modified. The v1.2.0 APK hash is unchanged.
• Users' funds, keys, seeds or wallets. Nothing reachable from this server can access them. No transaction authority was exposed.
• Our website, and the PayNym and Soroban services. Separate hosts, untouched.

The modified manifest

Ashigaru mobile fetches this manifest (ashigaru_mobile_latest.txt) to learn its current version and, since v1.1.0, to update the PayNym and Soroban Tor URLs negating the requirement for an Ashigaru mobile app update. This is the same "Hanzaki" mechanism we described when we released v1.1.0. This incident was not that scenario. The mechanism itself was the target.

The attacker left the signed body within the manifest untouched and added six lines to the armor header above it, the block of Comment: lines which precedes the signed content. A cleartext PGP signature covers the body, not those headers.

Comment: pgp_signed_message_version=2147483647
Comment: latest_paynym_url_version=9999
Comment: paynym_url=http://paynym.attacker.example
Comment: latest_soroban_url_version=9999
Comment: soroban_url=http://soroban.attacker.example:8080
Comment: router: completed GET /xINJ8 for 200.2.1.2:45444, 404 Not Found in 10.6ms @ user/home.go:714(user.UsernameSubRoute)

The last line is an access log entry, not manifest data. It was pasted in from the server's own log output. It is the clearest artifact we have of how the file was assembled.

The version numbers were chosen to outrank the genuine 0005. 2147483647 is the largest value a 32 bit signed integer can hold, so no future legitimate manifest can exceed it.

The URLs point at attacker.example. The .example top level domain is reserved by RFC 2606 for documentation and cannot be registered or resolved, so no user traffic could have reached the attacker through this path.

For reference:

Genuine manifest SHA-256:  9222e350913b0d613afde5a2596f0ae211e4eaecd0e366a7dcb5162f458ac86a

Modified manifest SHA-256: 781173718abe66c5d393557e8bb5a32037294f2c8343929f73a434df2eee2575

v1.2.0 APK SHA-256:        fcff081c083b344f90551488a8a1584851f8a4c09178c62460e5c09302512b34

Why the signature did not stop this

The signature was genuine, and the signed body was byte identical to the real v1.2.0 manifest. Armor headers sit outside the region a cleartext signature covers, so one file can carry a valid signature and unauthenticated values at the same time.

Strict tools noticed something was wrong. gpg --verify on the modified file reports invalid clearsig header and gets no further, because the injected lines break the RFC 4880 framing. The verifier within the existing versions of Ashigaru mobile does not. Rather it returns verification success on the body, and then hands the entire message, headers included, to the code which extracts values. That code looks for paynym_url=, soroban_url= and the version keys anywhere in the text and takes the first match. The headers come first, so the headers win.

The flaw was not that Ashigaru mobile trusts an unsigned file, rather it verifies only one part of the file, then reads a different part.

This is why the server rectification alone is not sufficient enough on its own to close this loop. The manifest has since been corrected back to the genuine one, however every current Ashigaru mobile version would still accept a modified manifest if it were to be altered using the same method. A new Ashigaru mobile release is therefore required to patch this.

What changing the manifest required

Breaking into our server and editing that manifest are two different kinds of work, and both happened here.

The first took persistence, plus knowledge of the software we were running and of the vulnerabilities published against it. Automated scanning finds exposed services indiscriminately. Turning an outdated service into command execution, and then holding on to that access for a period of time, is deliberate work aimed at one particular host.

The second took something more specific. To know where to insert those six lines, whoever did this had to know that our app reads the armor header at all, that the signature does not cover it, and that our parser takes the first match rather than the authenticated one. They picked 2147483647 because it is the maximum a 32 bit integer can hold, and 9999 because it beats the value the genuine manifest was using. They used a reserved domain which cannot resolve. The Ashigaru mobile's code responsible for the app's automatic update of functionality URLs was read and understood before the manifest file was modified.

An intrusion into a server that is months behind on patches is not an unusual event. What makes this one worth a public notice is the second half, where someone took the access they had and used it to reach into an app, in a way which only works if you have read and understood how that app is built.

What we confirmed in testing

We loaded the modified manifest into the current public build of Ashigaru mobile v1.2.0 and observed it accept the injected values. The stored PayNym URL, Soroban URL and manifest version were all updated in-app with those stated in the modified manifest.

These testing steps used the manual paste path in-app. The automatic update path reaches the same handler and is affected in the same way, as is the stored configuration afterwards, which is reloaded and applied without any further signature checking. Restoring the manifest to the genuine one on the server therefore does not repair an install which already accepted it. Fixing this issue is non-negotiable.

Why we cannot tell you whether your app was affected

We have no telemetry, and the intruder redirected server logs before the window closed, so we cannot reconstruct which clients fetched the modified manifest between 06:36 and 07:55. The guidance below is for everyone running v1.1.0 or later who may have unlocked their Ashigaru mobile app during that time window.

What you should do

Open your Ashigaru mobile app, unlock using your PIN, wait for the app to finish loading.

Check your PayNym and Soroban URLs. Navigate to Settings > About > App functionality URLs. If either shows a value ending in attacker.example, or anything other than the two URLs below, it was replaced. The correct values are:

PayNym URL:  paynym25chftmsywv4v2r67agbrr62lcxagsf4tymbzpeeucucy2ivad.onion
Version 0001

Soroban URL: soro2shclhp2mnufrolcxci623mqyiy6cczkpct7xelz5bhbxquxx6ad.onion:80
Version 0003

If your app is affected and the genuine valid PayNym and Soroban URLs are not displayed, you should following one of the two actions below:

Action A - uninstall and reinstall Ashigaru mobile app:

1. Make sure you know your wallet passphrase.
2. Confirm your seed phrase is written down and readable.
3. Uninstall and reinstall Ashigaru mobile, then restore from your seed + passphrase.
   After reinstalling, the genuine functionality URLs will be restored.

Note: A reinstall restores the genuine functionality URLs, but it does not make a current build safe from the parser flaw. It could be affected again by a modified manifest, which is why a new Ashigaru mobile release is required to fix this flaw permanently. Until an app update ships, the restored genuine manifest is served from a rebuilt server, and the main repo branch is now protected so that commits to it are no longer open to anyone who reaches the host. We will announce on this site when the next Ashigaru mobile release is released for you to update to.

OR follow Action B

Action B - wait for the next Ashigaru mobile app version, then update to this:
We have committed to fixing a poisoned app when it is updated to the next version of Ashigaru mobile app. We have not yet released an Ashigaru mobile update, so this action would have to be postponed until then. In the meantime if your current Ashigaru mobile app has poisoned PayNym and Soroban URLs you will have degraded functionality when interacting with wallet functionality that rely on these (e.g. user interface not displaying correctly the PayNym Pepehash avatars or PayNym names, and the inability to initiate or collaborate in online Cahoots Stowaway or StonewallX2 transactions). Furthermore you will not be notified in-app when a new version of Ashigaru mobile is available (so you will have to monitor this site for when the next mobile app release is available). After updating to the next Ashgaru mobile release, the genuine functionality URLs will be restored.

On intent

What was intended here is genuinely unclear to us, and the evidence allows for more than one reading.

One is a capability demonstration: an unresolvable address (attacker.example) chosen on purpose so the tampering could be shown without redirecting anyone, a calling card rather than a weapon. The other is an unfinished payload: the first writable field found and filled with obvious placeholders before anything more pointed followed, cut short perhaps when the service was taken down.

Either way the modified file sat on a live server for two hours and forty minutes, and the server itself ran for more than two hours after the intrusion began. The server was taken offline because we saw a service failing, not because we understood an attack. We cannot honestly claim we stopped this early, and we cannot claim it failed either.

What we can show is less flattering and sufficient. An unauthorized party had command execution on our release infrastructure, modified a file our app trusts, and we have confirmed the app accepted the modified values.

A request to anyone who finds something like this

Please tell us privately first, rather than opening a public issue or publishing.

This report from anonymous reached us within three hours of the tampering, and it is the reason we can publish a specific technical account instead of a vague one. A short, partial and careful report beat our own discovery here. A report which says "I have not tested this, and I am not claiming a compromise" is worth more to us than a confident one which turns out to be wrong.

We commit to answering, to crediting you in whichever way you prefer, by name, by handle or anonymously, and to not treating good faith security research as hostile. In return we ask for enough time to fix and ship before publication, and for restraint on live systems. Confirm what you need to confirm, then write to us.

What we have done

• Restored main to the genuine signed state. No new signature was required, because the signed body was never touched.
• Updated our Git software to the current release, pinned by image digest so it cannot drift out of date again. Gitea dropped the leading 1. from its version numbers in September 2026, so the active version is now the direct successor to the line we were running, and the numbering is correct.
• Updated the host operating system.
• Protected main, which the anonymous report correctly flagged as unprotected.
• Rebuilt the application container from a verified image and confirmed the Git binary against its published hash.
• Revoked every credential and token created during the intrusion, and removed the account involved.
• Removed the persistence mechanism left on the host.
• Capped container log retention, which an earlier stage of this incident had allowed to consume disk.
• Added a monthly review of upstream security advisories, server credentials and repository configuration.
• Added a check that the patch application endpoint rejects unauthenticated requests, so a future regression is visible.
• Preserved the modified file, the attacker's second copy and our reconstruction as evidence.

What we are changing

Note: none of this is in an updated Ashigaru mobile build yet, and we will publish a further notice when it is.

• The parser will not read values from unsigned armor headers. Version numbers and URLs will be accepted only from the verified signed body, and verification will complete before any field is consumed. This is the underlying flaw within the mobile app, and it is being fixed in a new app release alongside other security hardening.
• Framing errors will fail closed. A manifest which does not parse as clean cleartext signed data will be discarded with no state change.
• Version values will be bounded and checked, so an out of range number is discarded rather than persisted, and a manifest cannot roll a client backwards.
• The update URLs will move inside the signed body, so the armor block is never consulted for anything.
• We are evaluating hosting the manifest somewhere other than the Git server, so that compromising the Git host alone cannot change what clients are told.
• We are fixing how we track upstream releases, so a version which has been superseded for months cannot go unnoticed again.

Reminder

This website is the home of the Ashigaru Open Source Project. We do not hold a social media presence, nor have any other method of letting you know about the latest news related to this project. You should always verify information, or second-hand information, with what is stated on this website.

If you would like to get in contact with us, please do so via encrypted email following the steps here.

Thank you

We extend our sincere thanks to all who have downloaded, tried, and used Ashigaru mobile, provided valuable feedback and code reviews, as well as those who have graciously made donations to the Ashigaru Open Source Project. Your support is very much appreciated.

Thanks also to the anonymous user who reported this. They read our code closely enough to find a flaw we had missed, and they gave us the mechanism rather than a vague warning.

The fix for that flaw is being written now, and it will ship in the next release, with this notice updated to say so. The update URLs will live inside the signed text, the Git host will no longer be able to change what clients are told, and our release process is being monitored upstream. Bitcoin is unforgiving of mistakes, so we would rather tell you plainly when we make one than have you find out afterwards. Thank you for staying with us while we finalize the mobile app fix.

Signed version of this notice

To prove authenticity of this notice and the contents contained within, below is a PGP signed markdown message which may be verified against the Ashigaru PGP public key availalbe on Keybase:

• Keybase Ashigaru Dev - Clearnet URL
• Keybase Ashigaru Dev - Tor .onion URL

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

# Security notice: unauthorized access to our Git server and modification of the app update manifest

**Published:** Nov 12, 2026.
**Affects:** Ashigaru mobile v1.0.0 and later. PayNym and Soroban URL replacement could only have occurred on v1.1.0 or later.
**Bitcoin at risk:** None identified.
**Action required:** check your PayNym and Soroban functionality URLs in Ashigaru mobile. See "What you should do" below.
**App fix:** in development, not yet released. See "What we are changing" below.

## Overview

On Nov 5, 2026 (~06:29 UTC) an unauthorized party obtained command execution on the server which hosts the Ashigaru source code and release files. While they were there, they modified `ashigaru_mobile_latest.txt`, the PGP signed manifest which Ashigaru mobile uses to check for new versions and to update its PayNym and Soroban Tor URLs.

They did not forge a signature, and they did not obtain any signing key. They added six lines to the part of the file which a PGP signature does not cover.

In testing we have confirmed that Ashigaru mobile accepts version numbers and URLs from that unsigned part, and applies them. We have restored the genuine manifest and rebuilt the server.

The parser behavior itself is not yet fixed in a new release of Ashigaru mobile. A corrected build is currently in development and will be released, and we will publish a further notice when it is available to download and install. Until then, the server-side work described below is what stands between the Ashigaru mobile app and a modified manifest, and the checks in "What you should do" still apply to every current build.

* * *

## What happened

Our Git server was running an outdated release of our Git software, on an operating system which was also behind on its updates. That software was exposed to publicly disclosed vulnerabilities which allow an unauthenticated attacker to run commands on the server and to read files which the service can access. Those issues had been fixed upstream months earlier. We had not applied the available patches/updates.

We have not finished establishing which specific vulnerability was exploited, and we will not claim it was a particular one until we can show it. What we can say is that we were behind on both the Git application and host software version, that the updates were available, and we were not monitoring for new releases. That is the cause, and it is ours.

The container was running from a moving tag which we did not re-pull since June 2026. That detail is embarrassing rather than decisive, because it made an old image look current, but the real problem is that we had no routine for tracking security releases upstream. We have one now.

Once on the server, the attacker:

- - - modified the signed release manifest used by Ashigaru mobile;
- - - searched the host for Android signing keystores and PGP private keys, a search script which returned an empty result at 07:32 UTC;
- - - read our APK build documentation;
- - - wrote commits directly into the repository on disk, requiring no Git identity and no Gitea account due to local access;
- - - created an account and API tokens to keep working;
- - - left a persistence mechanism on the host (which we later identified and removed).

All of it ended when the service was taken offline.

**We took the service offline at 09:16 UTC, before the report described below reached us at 09:48 UTC.** We observed access to repository pages beginning to fail at around 07:55 and powered the server off as a precaution, without yet understanding the cause. The report shared with us did not trigger our response. It told us what we had been responding to, and it did so with a precision we had not reached ourselves.

* * *

## An anonymous user found this before we did

We are crediting this report to an anonymous user who was reviewing v1.2.0 before installing it, and noticed five unsigned commits on the `main` branch.

They read the v1.2.0 source code carefully rather than guessing. They predicted the exact mechanism, that the signature was checked against the signed text while the values were read from the whole message, with `substringBetween` taking the first match, so the unsigned header would win. They supplied SHA-256 hashes for both the genuine and the modified file. They wrote to us privately rather than opening a public issue, and they were careful to state which parts they had not tested and could not know.

Every technical claim in that report has since been confirmed, including by our internal tests. Our reply asked how the reporter wished to be credited. This is published anonymously, at their request.

* * *

## Timeline

All times UTC.

| When | Event |
|---|---|
| Nov 4, 19:59 | v1.2.0 manifest signed |
| Nov 4, 22:06 | v1.2.0 released |
| Nov 5, ~06:29 | Intrusion begins, attacker obtains command execution |
| Nov 5, 06:36 | Modified manifest committed to `main` |
| Nov 5, ~07:55 | Repository pages begin returning errors |
| Nov 5, 09:16 | Server powered off as a precaution, cause not yet known |
| Nov 5, 09:48 | Private report received from an anonymous user |
| Nov 6 | Modified manifest identified and verified against the genuine file |
| Nov 7 | Server rebuilt from a verified image, persistence removed, credentials revoked |
| Nov 8 | Git software and host updated, `main` protected |
| Nov 10 | Genuine manifest restored, service returned |
| Nov 11 | This notice published |                                                         |

- - From the commit at 06:36 to the service going down at 09:16 is two hours and forty minutes, and that is the full window in which the modified file could have been served.

* * *

## What was not compromised

- - - **Our PGP release signing key.** It has never been on this server. Our public key is published on Keybase only, deliberately not on this website and not on the Git server, so that compromising the Git host cannot influence what a user trusts. The signature on the genuine manifest remains valid.
- - - **Our Android APK signing keystore.** Not stored on this server, and not found by the attacker's search.
- - - **Any released APK, binary or signature file.** None were modified. The v1.2.0 APK hash is unchanged.
- - - **Users' funds, keys, seeds or wallets.** Nothing reachable from this server can access them. No transaction authority was exposed.
- - - **Our website, and the PayNym and Soroban services.** Separate hosts, untouched.

* * *

## The modified manifest

Ashigaru mobile fetches this manifest (`ashigaru_mobile_latest.txt`) to learn its current version and, since v1.1.0, to update the PayNym and Soroban Tor URLs negating the requirement for an Ashigaru mobile app update. This is the same "Hanzaki" mechanism we described when we released v1.1.0. This incident was not that scenario. The mechanism itself was the target.

The attacker left the signed body within the manifest untouched and added six lines to the armor header above it, the block of `Comment:` lines which precedes the signed content. A cleartext PGP signature covers the body, not those headers.

```
Comment: pgp_signed_message_version=2147483647
Comment: latest_paynym_url_version=9999
Comment: paynym_url=http://paynym.attacker.example
Comment: latest_soroban_url_version=9999
Comment: soroban_url=http://soroban.attacker.example:8080
Comment: router: completed GET /xINJ8 for 200.2.1.2:45444, 404 Not Found in 10.6ms @ user/home.go:714(user.UsernameSubRoute)
```

The last line is an access log entry, not manifest data. It was pasted in from the server's own log output. It is the clearest artifact we have of how the file was assembled.

The version numbers were chosen to outrank the genuine `0005`. **`2147483647` is the largest value a 32 bit signed integer can hold, so no future legitimate manifest can exceed it.**

The URLs point at `attacker.example`. The `.example` top level domain is reserved by RFC 2606 for documentation and cannot be registered or resolved, so **no user traffic could have reached the attacker through this path.**

For reference:

```
Genuine manifest SHA-256:  9222e350913b0d613afde5a2596f0ae211e4eaecd0e366a7dcb5162f458ac86a

Modified manifest SHA-256: 781173718abe66c5d393557e8bb5a32037294f2c8343929f73a434df2eee2575

v1.2.0 APK SHA-256:        fcff081c083b344f90551488a8a1584851f8a4c09178c62460e5c09302512b34
```

## Why the signature did not stop this

The signature was genuine, and the signed body was byte identical to the real v1.2.0 manifest. Armor headers sit outside the region a cleartext signature covers, so one file can carry a valid signature and unauthenticated values at the same time.

Strict tools noticed something was wrong. `gpg --verify` on the modified file reports `invalid clearsig header` and gets no further, because the injected lines break the RFC 4880 framing. The verifier within the existing versions of Ashigaru mobile does not. Rather it returns verification success on the body, and then hands the entire message, headers included, to the code which extracts values. That code looks for `paynym_url=`, `soroban_url=` and the version keys anywhere in the text and takes the first match. The headers come first, so the headers win.

The flaw was not that Ashigaru mobile trusts an unsigned file, rather it verifies only one part of the file, then reads a different part.

This is why the server rectification alone is not sufficient enough on its own to close this loop. The manifest has since been corrected back to the genuine one, however every current Ashigaru mobile version would still accept a modified manifest if it were to be altered using the same method. A new Ashigaru mobile release is therefore required to patch this.

## What changing the manifest required

Breaking into our server and editing that manifest are two different kinds of work, and both happened here.

The first took persistence, plus knowledge of the software we were running and of the vulnerabilities published against it. Automated scanning finds exposed services indiscriminately. Turning an outdated service into command execution, and then holding on to that access for a period of time, is deliberate work aimed at one particular host.

The second took something more specific. To know where to insert those six lines, whoever did this had to know that our app reads the armor header at all, that the signature does not cover it, and that our parser takes the first match rather than the authenticated one. They picked `2147483647` because it is the maximum a 32 bit integer can hold, and `9999` because it beats the value the genuine manifest was using. They used a reserved domain which cannot resolve. The Ashigaru mobile's code responsible for the app's automatic update of functionality URLs was read and understood before the manifest file was modified.

An intrusion into a server that is months behind on patches is not an unusual event. What makes this one worth a public notice is the second half, where someone took the access they had and used it to reach into an app, in a way which only works if you have read and understood how that app is built.

## What we confirmed in testing

We loaded the modified manifest into the current public build of Ashigaru mobile v1.2.0 and observed it accept the injected values. The stored PayNym URL, Soroban URL and manifest version were all updated in-app with those stated in the modified manifest.

These testing steps used the manual paste path in-app. The automatic update path reaches the same handler and is affected in the same way, as is the stored configuration afterwards, which is reloaded and applied without any further signature checking. Restoring the manifest to the genuine one on the server therefore does not repair an install which already accepted it. Fixing this issue is non-negotiable.

## Why we cannot tell you whether your app was affected

We have no telemetry, and the intruder redirected server logs before the window closed, so we cannot reconstruct which clients fetched the modified manifest between 06:36 and 07:55. The guidance below is for everyone running v1.1.0 or later who may have unlocked their Ashigaru mobile app during that time window.

* * *

## What you should do

Open your Ashigaru mobile app, unlock using your PIN, wait for the app to finish loading.

**Check your PayNym and Soroban URLs.** Navigate to `Settings > About > App functionality URLs`. If either shows a value ending in `attacker.example`, or anything other than the two URLs below, it was replaced. The correct values are:

```
PayNym URL:  paynym25chftmsywv4v2r67agbrr62lcxagsf4tymbzpeeucucy2ivad.onion
Version 0001

Soroban URL: soro2shclhp2mnufrolcxci623mqyiy6cczkpct7xelz5bhbxquxx6ad.onion:80
Version 0003
```

**If your app is affected** and the genuine valid PayNym and Soroban URLs are not displayed, you should following one of the two actions below:

**Action A - uninstall and reinstall Ashigaru mobile app**
1. Make sure you know your wallet passphrase.
2. Confirm your seed phrase is written down and readable.
3. Uninstall and reinstall Ashigaru mobile, then restore from your seed + passphrase.
After reinstalling, the genuine functionality URLs will be restored.

Note: A reinstall restores the genuine functionality URLs, but it does not make a current build safe from the parser flaw. It could be affected again by a modified manifest, which is why a new Ashigaru mobile release is required to fix this flaw permanently. Until an app update ships, the restored genuine manifest is served from a rebuilt server, and the `main` repo branch is now protected so that commits to it are no longer open to anyone who reaches the host. We will announce on this site when the next Ashigaru mobile release is released for you to update to.

OR follow Action B

**Action B - wait for the next Ashigaru mobile app version, then update to this**
We have committed to fixing a poisoned app when it is updated to the next version of Ashigaru mobile app. We have not yet released an Ashigaru mobile update, so this action would have to be postponed until then. In the meantime if your current Ashigaru mobile app has poisoned PayNym and Soroban URLs you will have degraded functionality when interacting with wallet functionality that rely on these (e.g. user interface not displaying correctly the PayNym Pepehash avatars or PayNym names, and the inability to initiate or collaborate in online Cahoots Stowaway or StonewallX2 transactions). Furthermore you will not be notified in-app when a new version of Ashigaru mobile is available (so you will have to monitor this site for when the next mobile app release is available). After updating to the next Ashgaru mobile release, the genuine functionality URLs will be restored.


* * *

## On intent

What was intended here is genuinely unclear to us, and the evidence allows for more than one reading.

One is a capability demonstration: an unresolvable address (`attacker.example`) chosen on purpose so the tampering could be shown without redirecting anyone, a calling card rather than a weapon. The other is an unfinished payload: the first writable field found and filled with obvious placeholders before anything more pointed followed, cut short perhaps when the service was taken down.

Either way the modified file sat on a live server for two hours and forty minutes, and the server itself ran for more than two hours after the intrusion began. The server was taken offline because we saw a service failing, not because we understood an attack. We cannot honestly claim we stopped this early, and we cannot claim it failed either.

What we can show is less flattering and sufficient. An unauthorized party had command execution on our release infrastructure, modified a file our app trusts, and we have confirmed the app accepted the modified values.

* * *

## A request to anyone who finds something like this

Please tell us privately first, rather than opening a public issue or publishing.

This report from anonymous reached us within three hours of the tampering, and it is the reason we can publish a specific technical account instead of a vague one. A short, partial and careful report beat our own discovery here. A report which says "I have not tested this, and I am not claiming a compromise" is worth more to us than a confident one which turns out to be wrong.

We commit to answering, to crediting you in whichever way you prefer, by name, by handle or anonymously, and to not treating good faith security research as hostile. In return we ask for enough time to fix and ship before publication, and for restraint on live systems. Confirm what you need to confirm, then write to us.

* * *

## What we have done

- - - Restored `main` to the genuine signed state. No new signature was required, because the signed body was never touched.
- - - Updated our Git software to the current release, pinned by image digest so it cannot drift out of date again. Gitea dropped the leading `1.` from its version numbers in September 2026, so the active version is now the direct successor to the line we were running, and the numbering is correct.
- - - Updated the host operating system.
- - - Protected `main`, which the anonymous report correctly flagged as unprotected.
- - - Rebuilt the application container from a verified image and confirmed the Git binary against its published hash.
- - - Revoked every credential and token created during the intrusion, and removed the account involved.
- - - Removed the persistence mechanism left on the host.
- - - Capped container log retention, which an earlier stage of this incident had allowed to consume disk.
- - - Added a monthly review of upstream security advisories, server credentials and repository configuration.
- - - Added a check that the patch application endpoint rejects unauthenticated requests, so a future regression is visible.
- - - Preserved the modified file, the attacker's second copy and our reconstruction as evidence.

## What we are changing

Note: none of this is in an updated Ashigaru mobile build yet, and we will publish a further notice when it is.

- - - **The parser will not read values from unsigned armor headers.** Version numbers and URLs will be accepted only from the verified signed body, and verification will complete before any field is consumed. This is the underlying flaw within the mobile app, and it is being fixed in a new app release alongside other security hardening.
- - - **Framing errors will fail closed.** A manifest which does not parse as clean cleartext signed data will be discarded with no state change.
- - - **Version values will be bounded and checked**, so an out of range number is discarded rather than persisted, and a manifest cannot roll a client backwards.
- - - **The update URLs will move inside the signed body**, so the armor block is never consulted for anything.
- - - **We are evaluating hosting the manifest somewhere other than the Git server**, so that compromising the Git host alone cannot change what clients are told.
- - - **We are fixing how we track upstream releases**, so a version which has been superseded for months cannot go unnoticed again.

* * *

## Reminder

This website is the home of the Ashigaru Open Source Project. We do not hold a social media presence, nor have any other method of letting you know about the latest news related to this project. You should always verify information, or second-hand information, with what is stated on this website.

If you would like to get in contact with us, please do so via encrypted email following the steps [here](https://ashigaru.rs/contact/).

* * *

## Thank you

We extend our sincere thanks to all who have downloaded, tried, and used Ashigaru mobile, provided valuable feedback and code reviews, as well as those who have graciously made donations to the Ashigaru Open Source Project. Your support is very much appreciated.

Thanks also to the anonymous user who reported this. They read our code closely enough to find a flaw we had missed, and they gave us the mechanism rather than a vague warning.

The fix for that flaw is being written now, and it will ship in the next release, with this notice updated to say so. The update URLs will live inside the signed text, the Git host will no longer be able to change what clients are told, and our release process is being monitored upstream. Bitcoin is unforgiving of mistakes, so we would rather tell you plainly when we make one than have you find out afterwards. Thank you for staying with us while we finalize the mobile app fix.

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEERF+AeZb3BYa3Fce4oTgGsfoqZ2sFAmr18QQACgkQoTgGsfoq
Z2vzoRAApgNMikgSLQY7H4rjf08l4BDf3bn2NC7Gp2JqUtmP8ncB/tGFkq93sM4o
P3lX2CW6bJpjdKdqvR43IBoyMwLpoCKPMZrh5jANHR8Bv6OZLpJZla1ZVXw/YMWP
Ylx3hw5M3E+9vJiDuE+vXMooje7AHQvJuwhSV5aLEPb04N+kJbsbWfskJymigQkC
tXMP6v6RXzaeBwvk/9qTgHYQirgYU9536YDoIK4MFv/pcPg3RESbBSNsbGqWUYZn
hULXB072VgEsB+/SwIylCneE50G8IzPB5n5NKqdYWQWvpeY56fY5JtauP86jLAaB
7FASZHVrSGr6zUJ1/nbR3Ww0U98xtDc+s8LdRLYvCNm4Pl7H8pbICCennu687525
zkS7yOU6kmK4lvWp3Bi7nCia61uvHpx5UBWqzo2fu/IF4TOUKZ6Lg2/PvSHoHsZ/
O8Xxye9+l8o0tig/TMX2qXzKyC1ugn7R1aSBkcYknnfEFU8A/0Hj/amu+avqE3+T
9Hx168fRZqskx5ewu4KcotRjf+ZX9MYYZ2D8STVu/CvpyGismLTHhYHGsOLuIrfJ
MztpxYB4apPKzLm6Tcre6iCEDPGTlovTTghQBIXNa3jDxc+HvapNW+LmAU+WKNEd
cHBlRzSDnkkqjw76T5Z87JwEYoBymteknWqCKCO7PSbLGN7xXGw=
=D52E
-----END PGP SIGNATURE-----