NginxProxyManager / NginxProxyManager/nginx-proxy-manager

Access List is not enforced after disabling and re-enabling a Proxy Host

Open
#5,710 3 comments 2 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

bug
Dominant language
TypeScript
Stars
34.2k
Forks
3.9k
Avg merge
21h 12m
Merged PRs (30d)
20

Description

Checklist

  • Have you pulled and found the error with jc21/nginx-proxy-manager:latest docker image?
    • Yes
  • Are you sure you're not using someone else's docker image?
    • Yes
  • Have you searched for similar issues (both open and closed)?
    • Yes

Describe the bug

After disabling and re-enabling a Proxy Host, the assigned Access List is no longer enforced.

The Nginx Proxy Manager web interface continues to display the Access List as assigned to the Proxy Host, suggesting that the configured protection is still active. However, requests are forwarded directly to the upstream service without applying either the configured IP restrictions or Basic Authentication.

Opening the Proxy Host configuration and simply clicking Save immediately restores the expected behavior.

This can unintentionally expose services to the Internet while the UI still indicates that they are protected.

Nginx Proxy Manager Version

2.15.1

Also reproduced using the current jc21/nginx-proxy-manager:latest Docker image.

Access List configuration

The Access List used for testing was configured as follows:

  • Satisfy: Any
  • Pass Authentication: Disabled
  • Basic Authentication: Enabled (single test user)
  • Access rules:
    • Allow: 10.1.0.0/21
    • Allow: fd00::/64
    • Deny: all

To Reproduce

  1. Create a Proxy Host.
  2. Assign the Access List described above.
  3. Save the Proxy Host.
  4. Verify that the Access List is enforced (authentication and IP restrictions work as expected).
  5. Disable the Proxy Host.
  6. Re-enable the Proxy Host.
  7. Access the Proxy Host from an external network.

Expected behavior

The assigned Access List should remain active after the Proxy Host is disabled and re-enabled.

Basic Authentication and IP restrictions should continue to be enforced until the Access List is explicitly changed or removed.

Actual behavior

After re-enabling the Proxy Host, the Access List is no longer enforced.

Requests are forwarded directly to the upstream service without requiring authentication or applying the configured IP restrictions, even though the NPM UI still shows the Access List as assigned.

Opening the Proxy Host configuration and saving it again immediately restores the expected behavior.

Operating System

  • Debian
  • Docker Compose
  • Docker image: jc21/nginx-proxy-manager:latest
  • Also reproduced with jc21/nginx-proxy-manager:2.15.1

Additional context

This issue appears to have security implications because administrators may believe a service is still protected by an Access List while it is actually publicly accessible.

The behavior is consistently reproducible on my installation.

Opening and saving the Proxy Host immediately restores the expected behavior until the Proxy Host is disabled and re-enabled again.

I can provide logs, screenshots, generated Nginx configuration files, or any additional information required to help reproduce and diagnose the issue.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reproducing the disable-and-re-enable sequence with the stated Access List, then compare the generated Nginx configuration and request behavior before and after. Confirm that the re-enabled Proxy Host enforces both Basic Authentication and the IP rules without requiring another configuration save.

Written by the indexing model from the issue text.

Assessment

Tech stack
docker-compose, nginx, typescript
Domain
devops, security
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
57/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.