AdventureLog exposure needs a first-login and API-key review

AdventureLog combines travel records, photos, map data, and integrations in a self-hosted application. Its README makes the security features visible: MFA, API keys, and social authentication. It also documents a default admin / admin login that should be changed immediately. That combination creates a clear first-login question for every internet-facing deployment.

On 9 November 2026 at 08:50 Asia/Shanghai, a ZoomEye query using sub_type=all, page 1, and page size 1 returned 204 assets for title="AdventureLog" && http.body="AdventureLog". The title query returned 205 and the body query returned 256. The application fingerprint returned zero, so this is a title-and-body inventory rather than an application-fingerprint confirmation.

The query is reproducible through the selected ZoomEye search.

Default credentials are an installation state

The project's README states that the default login is admin / admin and recommends changing it immediately after the first sign-in. The first-login check belongs in deployment validation, not only in a README warning. An installer can finish successfully while the service remains on the default credential.

Test the default account from a network position that matches the public edge. Do not assume that a reverse proxy or VPN removes the risk if the application is reachable through another path. Verify that the password was changed, MFA is enrolled where required, and the account is not shared by multiple operators.

The default account is also an ownership problem. If the first administrator leaves, someone must still be able to recover the instance without reusing the shared credential. Record the account owner and the recovery process the same way you would for a production database.

API keys create a second authentication path

AdventureLog documents API keys as a security feature. The release notes describe a move to API-key authentication for the Wanderer integration and MFA support for another service. API keys are useful for automation, but they can outlive the browser session that created them.

Inventory every API key by owner, integration, scope if available, creation date, and last use. Revoke keys for deleted users and abandoned integrations. Do not put an API key in a URL that is copied into logs or browser history. Keep it in an environment or secret store and send it through the integration's supported header.

A key that can read travel records, photos, or linked experiences has a data-access footprint. Review the API path as well as the UI. A user who cannot open a private adventure in the browser may still be able to fetch the same object through an API endpoint if the permission layer is inconsistent.

OIDC needs an account lifecycle

AdventureLog can use OIDC as a social identity provider. The configuration documentation points operators to their identity provider's client and server settings. The integration is not complete until the operator defines what happens when an identity is disabled, renamed, or moved between groups.

Test a user who has both a local password and a social login. Confirm whether disabling one path disables the account or leaves the other path active. Review the administrator role mapping and the process for removing a user's access to private content.

The application supports public and private visibility for travel content. A user may intentionally publish a trip while keeping photos or precise locations private. Test those combinations with a second account. A public map should not expose a protected media object merely because the two are associated in the interface.

A deployment checklist for an owned host

Start from the public edge and try the first-login page. Confirm the default password is gone. Sign in as an administrator and review MFA, social login, account recovery, and active API keys. Then create a test user with ordinary permissions and attempt to read another user's private adventure.

Check the reverse proxy and the application's trusted-origin settings together. A CSRF trusted-origin list or a forwarded-header configuration can be correct in one layer and overly broad in another. Test the login form from the external hostname and from a header path that the proxy is expected to reject.

The 204 matches are not a count of default installations. They identify pages that combine the AdventureLog title and body markers. The useful next step is to compare each owned deployment with a first-login, identity, and API-key checklist. The security features matter only after the default state and the second access path are both closed.

References

• AdventureLog GitHub repository, README
• AdventureLog documentation, OIDC social authentication
• AdventureLog releases, Release notes and security changes