Mintplex-Labs/anything-llm
1
0
Fork 0
mirror of https://github.com/Mintplex-Labs/anything-llm.git synced 2026-07-19 22:23:50 -04:00
Code Issues 328 Packages Projects Releases 10 Wiki Activity

[GH-ISSUE #4301] [FEAT]: Mandatory first-run auth, inference-only mode, and stricter defaults #2736

New Issue
Closed
opened 2026-02-22 18:31:00 -05:00 by yindo · 2 comments
yindo commented 2026-02-22 18:31:00 -05:00
Owner
Copy Link
Copy Source

Originally created by @Cristliu on GitHub (Aug 17, 2025).
Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/4301

What would you like to see?

Summary

Our study finds that AnythingLLM can be deployed without passwords by default, and a non-trivial subset of public instances lack access control. In our lab testbed (not the open Internet), an unauthenticated user could view conversations and perform admin operations—illustrating the risk when auth is absent.

Why it matters

Unauthenticated frontends expose private chats and may grant admin-level actions, enabling workspace/KB tampering and data leakage.

Requested features / suggestions

  • First-run setup is mandatory: block access to any UI/API until an admin account and strong password are created.
  • Inference-only mode: a flag to disable admin/workspace endpoints entirely for public demos.
  • Endpoint classification: explicit “public vs authenticated vs admin” routes, enforced server-side with rate limiting and CSRF/CORS safe defaults.
  • Security health panel: warn when running without auth, or when behind a proxy that exposes the service publicly.
  • Hardened examples: production compose with localhost binding and guidance for VPN/reverse-proxy.

Coordination

We can provide non-sensitive evidence privately and help validate candidate fixes.

Originally created by @Cristliu on GitHub (Aug 17, 2025). Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/4301 ### What would you like to see? ### Summary Our study finds that **AnythingLLM can be deployed without passwords by default**, and a **non-trivial subset** of public instances lack access control. In our lab testbed (not the open Internet), an unauthenticated user could view conversations and perform admin operations—illustrating the risk when auth is absent. ### Why it matters Unauthenticated frontends expose private chats and may grant admin-level actions, enabling workspace/KB tampering and data leakage. ### Requested features / suggestions - **First-run setup is mandatory**: block access to any UI/API until an admin account and strong password are created. - **Inference-only mode**: a flag to disable admin/workspace endpoints entirely for public demos. - **Endpoint classification**: explicit “public vs authenticated vs admin” routes, enforced server-side with rate limiting and CSRF/CORS safe defaults. - **Security health panel**: warn when running without auth, or when behind a proxy that exposes the service publicly. - **Hardened examples**: production compose with localhost binding and guidance for VPN/reverse-proxy. ### Coordination We can provide non-sensitive evidence privately and help validate candidate fixes.
yindo added the enhancementfeature request labels 2026-02-22 18:31:00 -05:00
yindo closed this issue 2026-02-22 18:31:01 -05:00
yindo commented 2026-02-22 18:31:01 -05:00
Author
Owner
Copy Link
Copy Source

@timothycarambat commented on GitHub (Aug 17, 2025):

First-run setup is mandatory: block access to any UI/API until an admin account and strong password are created.

This is intended. It's the 2nd question during onboarding if you want to use in single user mode (and optionally set a password) or in multi-user. The user can set this to whatever they like since we are not going to require them to set a password or multi-user permissioning if they dont want to. The choice is theirs.

All of the other suggestions are purely deployment/configuration related outside of the scope of AnythingLLM. If an admin wants to deploy AnythingLLM in an insecure manner, then that is 100% their responsibility. If they want rate-limiting, they can do that with whatever methodology or tool they wish to use.

We build the application, but the deployment is always an opinionated aspect, so we leave that totally up to the admin to set up, since if we enforce some kind of "only path" we will get 1000 issues about "support XYZ preference of mine". We don't block or limit any kind of deployment a user wants to use, so they are totally allowed to do whatever they like. Even if it is insecure 🤷‍♂️

@timothycarambat commented on GitHub (Aug 17, 2025): > First-run setup is mandatory: block access to any UI/API until an admin account and strong password are created. This is intended. It's the 2nd question during onboarding if you want to use in single user mode (and optionally set a password) or in multi-user. The user can set this to whatever they like since we are not going to require them to set a password or multi-user permissioning if they dont want to. The choice is theirs. All of the other suggestions are purely deployment/configuration related outside of the scope of AnythingLLM. If an admin wants to deploy AnythingLLM in an insecure manner, then that is 100% their responsibility. If they want rate-limiting, they can do that with whatever methodology or tool they wish to use. We build the application, but the deployment is always an opinionated aspect, so we leave that totally up to the admin to set up, since if we enforce some kind of "only path" we will get 1000 issues about "support XYZ preference of mine". We don't block or limit any kind of deployment a user wants to use, so they are totally allowed to do whatever they like. Even if it is insecure 🤷‍♂️
yindo commented 2026-02-22 18:31:01 -05:00
Author
Owner
Copy Link
Copy Source

@Cristliu commented on GitHub (Aug 17, 2025):

👍Thanks for the quick reply — totally understand the choice to keep deployment flexible.

Our goal isn’t to enforce anything, just to reduce operator mistakes we saw in the wild.
Maybe it can leave a small docs note (or onboarding sentence) like: “If the instance is reachable beyond localhost, enable multi-user with a strong password or put it behind an authenticated proxy.”

Thanks again!

@Cristliu commented on GitHub (Aug 17, 2025): 👍Thanks for the quick reply — totally understand the choice to keep deployment flexible. Our goal isn’t to enforce anything, just to reduce operator mistakes we saw in the wild. Maybe it can leave a small docs note (or onboarding sentence) like: *“If the instance is reachable beyond localhost, enable multi-user with a strong password or put it behind an authenticated proxy.”* Thanks again!
yindo changed title from [FEAT]: Mandatory first-run auth, inference-only mode, and stricter defaults to [GH-ISSUE #4301] [FEAT]: Mandatory first-run auth, inference-only mode, and stricter defaults 2026-06-05 14:48:15 -04:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Desktop
Docker
Integration Request
Integration Request
OS: Linux
OS: Mobile
OS: Windows
UI/UX
blocked
bug
bug
core-team-only
documentation
duplicate
embed-widget
enhancement
feature request
github_actions
good first issue
investigating
needs info / can't replicate
possible bug
pull-request
Mirrored from GitHub Pull Request
 question
stage: specifications
wontfix
No Label enhancement feature request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Mintplex-Labs/anything-llm#2736
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?