Akaunting
WarnAudited by ClawScan on May 10, 2026.
Overview
This appears to be a real Akaunting integration, but it can change accounting records and its Docker setup exposes a persistent service with weak default credentials.
Install only if you are prepared to secure the Akaunting server: change default passwords immediately, restrict port 8080, use HTTPS or a private network, protect the local config file, pin Docker images, and require manual review before any transaction or item is created.
Findings (5)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
Someone who can reach the service could potentially access or alter accounting data if default credentials remain active.
The provided deployment exposes the accounting web app on the host and configures a predictable default admin password. For financial software, that is high-impact unless the user immediately changes it and restricts access.
ports:
- "8080:80"
...
- ADMIN_EMAIL=admin@example.com
- ADMIN_PASSWORD=changeme123Bind the service to localhost or a private network, use a firewall, replace all default passwords before use, and document that users must not expose this setup publicly.
An agent could create incorrect income or expense records in the user’s books if it infers the wrong account, amount, date, or category.
The CLI can create live accounting transactions, defaults to the first account when none is supplied, and does not show a confirmation or dry-run step before the POST.
account_id = args.account or accounts["data"][0]["id"]
...
"paid_at": args.date or "2026-02-07"
...
result = api_request("POST", "transactions", config, data=data)Require explicit user confirmation for every write, show a preview of the exact transaction, avoid defaulting critical fields like account/date, and provide a clear correction or rollback workflow.
The user’s Akaunting password could be exposed to local users or over the network if permissions, TLS, and host access are not handled carefully.
Using Akaunting credentials is purpose-aligned, but the instructions store a password in a local config file and show an HTTP URL, which can expose credentials if the file or network is not protected.
"url": "http://YOUR_IP:8080", "email": "your@email.com", "password": "your-password" ... Authentication: HTTP Basic Auth with user email/password.
Use HTTPS or a trusted local/private network, restrict config file permissions, prefer a least-privileged API user, and avoid reusing an administrator password.
Future installs may run different Akaunting code than the version originally reviewed.
The deployment pulls container images, including an unpinned latest tag for Akaunting. This is normal for a Docker-based setup, but it reduces reproducibility and provenance control.
image: akaunting/akaunting:latest ... image: mariadb:10.6
Pin container images to specific versions or digests and review updates before deploying them.
Running the fix changes the Akaunting container’s application files and may be hard to undo without a backup or rebuild.
The helper script runs shell/PHP inside the Akaunting container and modifies an application PHP file. This is disclosed as a setup fix and appears purpose-aligned, but it is still code execution that changes the deployed app.
subprocess.run(["docker", "exec", CONTAINER_NAME, "bash", "-c", cmd], ...) ... file_put_contents($file, $content);
Inspect the script first, back up the container or volume, run it only against the intended Akaunting container, and prefer an upstream-patched version when available.
