Maintenance portlet: system config overrides displayed without obfuscation

Open Beginner friendly
#36,919 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
1/5
Estimated time
Under an hour
Newbie friendliness
88/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Quiet
Tech stack
java
Domain
backend, security

Research direction

Start at JVMInfoResource.getDBOverrides() and compare how its configOverrides values are handled with the existing obfuscateIfNeeded() use for system properties and environment variables. Confirm the change preserves the existing key-matching and configurable pattern rules, and that sensitive config overrides are no longer returned in plaintext.

Written by the indexing model from the issue text.

Description

Team : Platform Type : Defect

Problem

The JVM Info screen in the maintenance portlet (GET /api/v1/jvm) obfuscates sensitive values in the System Properties and Environment Variables sections via JVMInfoResource.obfuscateIfNeeded() (masks values whose key matches passw|pass|passwd|secret|key|token, plus the configurable OBFUSCATE_SYSTEM_ENVIRONMENTAL_VARIABLES pattern).

The configOverrides section does not: getDBOverrides() copies SystemTable.all() straight into the response, so any secret stored as a system-table config override (API keys, tokens, passwords set via the UI/API) is rendered in plaintext to anyone with maintenance-portlet access.

Fix

Apply the same obfuscateIfNeeded(key, value) rules to the config-overrides map — one line in JVMInfoResource.getDBOverrides().

Security note

Read access already requires a backend user with the maintenance portlet, so exposure is limited to authenticated admins — but the whole point of the existing obfuscation is that even admins shouldn't see raw secrets on a screen that gets screenshotted into support tickets.

Dominant language
Java
Stars
970
Forks
486
Avg merge
3d 2h
Merged PRs (30d)
164

Contributor guide

Open the contributing guide

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.

More from dotCMS/core

All issues in dotCMS/core

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.