github-starred/pangolin
2
0
Fork 0
mirror of https://github.com/fosrl/pangolin.git synced 2026-05-21 01:11:38 -05:00
Code Issues 856 Packages Projects Releases 74 Wiki Activity

[GH-ISSUE #1887] Urgent: User Session Length Not Enforced in Server Admin/New Organization Section or or Security-Sensitive Account Settings. #10797

New Issue
Closed
opened 2026-05-06 15:07:54 -05:00 by GiteaMirror · 2 comments
GiteaMirror commented 2026-05-06 15:07:54 -05:00
Owner
Copy Link

Originally created by @keonramses on GitHub (Nov 18, 2025).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/1887

Describe the Bug

Pangolin recently introduced a feature to enforce user session length, requiring users to re-authenticate after a configured duration.

While session enforcement works correctly for the main organization instance (user-facing UI), several critical areas continue to remain accessible even after the session has expired:

  • Server admin area
  • New organization section
  • Account security settings, including:
    • Enabling/disabling 2FA
    • Managing security keys
    • Changing passwords

This results in an incomplete session timeout that leaves highly sensitive sections available without requiring re-authentication.

https://github.com/user-attachments/assets/d7836c45-a79e-4f98-b019-c99c67e3d48a

Environment

OS Type & Version: Rocky Linux 10
Pangolin Version: ee-1.12.2
Gerbil Version: 1.2.2
Traefik Version: 3.5.3
Newt Version: 1.6.0
Olm Version: N/A

To Reproduce

  1. Enable and configure session length enforcement for the organization instance (e.g., 60 minutes).
  2. Log in as a user who has access to:
    • The organization instance
    • The new organization section
    • The server admin area
    • Personal security settings (2FA, security keys, password change)
  3. Wait until the configured session length has passed.
  4. Attempt to access various pages.

Expected Behaviour

Once the configured session duration expires:

  • All authenticated endpoints must require re-authentication.
  • Access to any privileged area (admin panel, org pages, account security pages) should be revoked.
  • Security-sensitive pages (2FA change, password update, key management) should always enforce session freshness.

Actual Results

  • Access to the main organization instance is correctly blocked (forced logout).
  • However, without re-authenticating, the user can still access:
    • New organization section
    • Server admin area (all actions are accessible)
    • Account security settings (2FA management, security keys, password change)

These pages continue working indefinitely, ignoring the session timeout.

Originally created by @keonramses on GitHub (Nov 18, 2025). Original GitHub issue: https://github.com/fosrl/pangolin/issues/1887 ### Describe the Bug Pangolin recently introduced a feature to enforce user session length, requiring users to re-authenticate after a configured duration. While session enforcement works correctly for the main organization instance (user-facing UI), several critical areas continue to remain accessible even after the session has expired: - Server admin area - New organization section - Account security settings, including: - Enabling/disabling 2FA - Managing security keys - Changing passwords This results in an incomplete session timeout that leaves highly sensitive sections available without requiring re-authentication. https://github.com/user-attachments/assets/d7836c45-a79e-4f98-b019-c99c67e3d48a ### Environment OS Type & Version: Rocky Linux 10 Pangolin Version: ee-1.12.2 Gerbil Version: 1.2.2 Traefik Version: 3.5.3 Newt Version: 1.6.0 Olm Version: N/A ### To Reproduce 1. Enable and configure session length enforcement for the organization instance (e.g., 60 minutes). 2. Log in as a user who has access to: - The organization instance - The new organization section - The server admin area - Personal security settings (2FA, security keys, password change) 3. Wait until the configured session length has passed. 4. Attempt to access various pages. ### Expected Behaviour Once the configured session duration expires: - All authenticated endpoints must require re-authentication. - Access to any privileged area (admin panel, org pages, account security pages) should be revoked. - Security-sensitive pages (2FA change, password update, key management) should always enforce session freshness. ### Actual Results - Access to the main organization instance is correctly blocked (forced logout). - However, without re-authenticating, the user can still access: - New organization section - Server admin area (all actions are accessible) - Account security settings (2FA management, security keys, password change) These pages continue working indefinitely, ignoring the session timeout.
GiteaMirror commented 2026-05-06 15:08:00 -05:00
Author
Owner
Copy Link

@miloschwartz commented on GitHub (Nov 19, 2025):

Thanks for reporting this. Although, FYI, please follow SECURITY.md in the future.

While this is a little confusing, this is intended behavior. It's a classic multi-tenant problem. How do you enforce account security on a user that exists in more than tenant?

Security controls are enforced per organization which is important because a user could exist in more than one organization with completely different security controls of different strictness. Therefore, they don't apply to higher level constructs like the user's profile (key, password change, etc), and the server admin panel. You can think of these existing security controls as securing an organization and all it's contents (resources).

Also, the server admin section is only available to the root user of the account. This is assumed to be controlled by the server owner with a good security posture and not end users, thus the security controls are not enforced.

To do what you're requesting would require a new feature to enforce these at the server level rather than the tenant level.

<!-- gh-comment-id:3550520503 --> @miloschwartz commented on GitHub (Nov 19, 2025): Thanks for reporting this. Although, FYI, please follow `SECURITY.md` in the future. While this is a little confusing, this is intended behavior. It's a classic multi-tenant problem. How do you enforce account security on a user that exists in more than tenant? Security controls are enforced *per organization* which is important because a user could exist in more than one organization with completely different security controls of different strictness. Therefore, they don't apply to higher level constructs like the user's profile (key, password change, etc), and the server admin panel. You can think of these existing security controls as securing an organization and all it's contents (resources). Also, the server admin section is only available to the root user of the account. This is assumed to be controlled by the server owner with a good security posture and not end users, thus the security controls are not enforced. To do what you're requesting would require a new feature to enforce these at the server level rather than the tenant level.
GiteaMirror commented 2026-05-06 15:08:01 -05:00
Author
Owner
Copy Link

@keonramses commented on GitHub (Nov 19, 2025):

Thank you for the explanation, and my apologies, I had a brain fart moment and did not look at the security.md

<!-- gh-comment-id:3550572722 --> @keonramses commented on GitHub (Nov 19, 2025): Thank you for the explanation, and my apologies, I had a brain fart moment and did not look at the security.md
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
api
authentication
bug
config
dependencies
docker
documentation
enhancement
good first issue
help wanted
Improvement
Look Into
needs investigating
networking
new feature
non-critical bug
potential bug
pull-request
Mirrored from GitHub Pull Request
 question
reverse proxy
Security
stale
ui
wontfix
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/pangolin#10797
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?