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

New Issue

GiteaMirror · 2026-04-16T08:59:24-05:00

GiteaMirror commented

2026-04-16 08:59:24 -05:00

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

Enable and configure session length enforcement for the organization instance (e.g., 60 minutes).
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)
Wait until the configured session length has passed.
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 closed this issue

2026-04-16 08:59:24 -05:00

GiteaMirror commented

2026-04-16 08:59:27 -05:00

@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.

@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-04-16 08:59:27 -05:00

@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

@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

GiteaMirror referenced this issue

2026-04-16 09:38:05 -05:00

[PR #2036] [MERGED] Bump @types/pg from 8.15.6 to 8.16.0 in the dev-minor-updates group #2835

GiteaMirror referenced this issue

2026-04-20 09:05:36 -05:00

[PR #2036] [MERGED] Bump @types/pg from 8.15.6 to 8.16.0 in the dev-minor-updates group #4778

GiteaMirror referenced this issue

2026-04-23 02:45:01 -05:00

[PR #2036] [MERGED] Bump @types/pg from 8.15.6 to 8.16.0 in the dev-minor-updates group #5722

GiteaMirror referenced this issue

2026-04-25 16:20:40 -05:00

[PR #2036] [MERGED] Bump @types/pg from 8.15.6 to 8.16.0 in the dev-minor-updates group #7637