Prevent anauthorized access to /system/console | Community
Skip to main content
A
anasustic
Level 6
June 10, 2026
Solved

Prevent anauthorized access to /system/console

  • June 10, 2026
  • 3 replies
  • 72 views

There appears to be a short window during system startup where the OSGi Management Console (/system/console) can be accessed using default or static credentials (e.g., admin:admin).
This window can allow unauthorized users with network access to gain admin rights if they know or guess the password, before the usual authentication/authorization mechanisms and custom user configs are fully in place.
What are best practices to completely prevent unauthorized access to /system/console during (and after) startup?

Best answer by akhil_merupula

Hi ​@anasustic,

 

What you’re seeing is expected behavior, and it explains the confusion: the OsgiManager username/password only applies when the JCR repository is unavailable.

 

In AEM, Felix Web Console authentication is delegated to the Sling WebConsoleSecurityProvider, which authenticates against the JCR repository. If you look at the OsgiManager config description closely, it says: “This property is ignored if a WebConsoleSecurityProvider is used for authentication.” That’s why admin:admin still works after your restart, it’s authenticating as the repository admin user, not via your OSGi config.

 

So two separate fixes:

 

1. Post-startup access (your current issue): change the repository admin password (Tools → Security → Users, or /crx/explorer). The web console will follow it immediately.

 

2. The startup window (your original question): this is exactly when the repository is down and the OsgiManager fallback credentials do apply. To protect it, don’t set them via ConfigMgr (too late in the lifecycle), deploy them as a config file picked up at boot:

crx-quickstart/install/org.apache.felix.webconsole.internal.servlet.OsgiManager.cfg.json

with your custom username/password. This way the fallback credentials are non-default from the very first second of startup.

 

3. Defense in depth: regardless of credentials, /system/console should never be network-reachable in production, block it at the dispatcher (/filter deny) and firewall it to localhost/VPN on author. On publish, consider whether the web console bundle is needed at all. (For reference, AEM as a Cloud Service removes /system/console access entirely, that’s the direction Adobe itself went.)


So: repository admin password covers normal runtime, the boot-time config file covers the startup window, and network restriction covers everything else.

3 replies

avesh_narang
avesh_narang
Level 4
June 10, 2026

Hi ​@anasustic ,

The best approach is to limit network access not exposing it publicly while AEM is starting and change the admin password right after you log in. 

 

Thanks 

    A
    anasusticAuthor
    Level 6
    June 11, 2026

    Hi ​@avesh_narang 

    The AEM Security Checklist https://experienceleague.adobe.com/en/docs/experience-manager-65/content/security/security-checklist suggests to To change the OSGi web console admin password
    What is the difference between the admin password and the admin password for the OSGi Web console?

    Thanks.

     

    G
    GR_Swaminathan
    Level 1
    June 11, 2026

    Hi ​@anasustic 


    These are two different credentials.

    admin password: stored in the JCR repository, governs access to the AEM UI, CRXDE, and all Sling-authenticated requests. 

    OSGi Web Console password: stored as an OSGi config (Apache Felix OSGi Management Console), governs access to /system/console. Active even during JCR startup/shutdown or repository failures.

    Hope this helps.

    A
    anasusticAuthor
    Level 6
    June 11, 2026

    Hi ​@GR_Swaminathan 

    Thanks for responding.

    It appears that the OSGi config (Apache Felix OSGi Management Console) user name and password have no affect since when I configure a new username and password in http://localhost:4502/system/console/configMgr/org.apache.felix.webconsole.internal.servlet.OsgiManager and restart the server I can still signon to  http://localhost:4502/system/console using admin:admin.

    A
    akhil_merupulaAccepted solution
    Level 4
    June 12, 2026

    Hi ​@anasustic,

     

    What you’re seeing is expected behavior, and it explains the confusion: the OsgiManager username/password only applies when the JCR repository is unavailable.

     

    In AEM, Felix Web Console authentication is delegated to the Sling WebConsoleSecurityProvider, which authenticates against the JCR repository. If you look at the OsgiManager config description closely, it says: “This property is ignored if a WebConsoleSecurityProvider is used for authentication.” That’s why admin:admin still works after your restart, it’s authenticating as the repository admin user, not via your OSGi config.

     

    So two separate fixes:

     

    1. Post-startup access (your current issue): change the repository admin password (Tools → Security → Users, or /crx/explorer). The web console will follow it immediately.

     

    2. The startup window (your original question): this is exactly when the repository is down and the OsgiManager fallback credentials do apply. To protect it, don’t set them via ConfigMgr (too late in the lifecycle), deploy them as a config file picked up at boot:

    crx-quickstart/install/org.apache.felix.webconsole.internal.servlet.OsgiManager.cfg.json

    with your custom username/password. This way the fallback credentials are non-default from the very first second of startup.

     

    3. Defense in depth: regardless of credentials, /system/console should never be network-reachable in production, block it at the dispatcher (/filter deny) and firewall it to localhost/VPN on author. On publish, consider whether the web console bundle is needed at all. (For reference, AEM as a Cloud Service removes /system/console access entirely, that’s the direction Adobe itself went.)


    So: repository admin password covers normal runtime, the boot-time config file covers the startup window, and network restriction covers everything else.

      Terms & ConditionsAccessibility statement

      Loading footer...