Sunday, October 12, 2025

Oracle E-Business Suite Hit by New High-Severity Vulnerability — CVE-2025-61884

 

Overview

Oracle has disclosed a new high-severity vulnerability (CVE-2025-61884) impacting Oracle E-Business Suite (EBS) versions 12.2.3 through 12.2.14, as outlined in My Oracle Support (MOS) Note 3107176.1.
This vulnerability follows closely on the heels of another critical issue — CVE-2025-61882, announced on October 4, 2025, which has already been observed in active exploitation campaigns.

Both vulnerabilities underscore the growing importance of timely patching, network hardening, and proactive monitoring for organizations running Oracle EBS on-premises or in the cloud.


⚠️ CVE-2025-61884 — What We Know So Far

  • Component Affected: Oracle Configurator (Runtime UI)

  • Affected Versions: EBS 12.2.3 to 12.2.14

  • Severity: High (CVSS v3.1 Base Score 7.5)

  • Access Vector: Network — unauthenticated HTTP access

  • MOS Reference: Doc ID 3107176.1

This vulnerability allows unauthenticated network access to the Oracle Configurator component, potentially exposing sensitive configuration data or enabling unauthorized access to system resources.
Oracle has released a security patch to address the issue, available through the Patch Availability Document in MOS.

In addition to applying the patch, Oracle recommends specific post-patch verification steps and tightened access controls around Configurator-related URLs.


🧩 CVE-2025-61882 — The Earlier Critical CVE Still Demands Attention

  • Component Affected: Oracle Concurrent Processing / BI Publisher Integration

  • Severity: Critical — Remote Code Execution (RCE)

  • MOS Reference: Doc ID 3106344.1

  • Status: Actively exploited in the wild

This earlier CVE exposed an RCE vulnerability that could be triggered via HTTP, allowing attackers to execute arbitrary code on EBS application servers.
It has been actively exploited by threat actors (including ransomware groups), leading Oracle and cybersecurity agencies to issue urgent patching advisories.

Organizations should ensure that:

  1. The CVE-2025-61882 patch has already been applied.

  2. Prerequisite CPU/PSU patches are installed before applying the emergency fix.

  3. Threat hunting and log analysis are performed for signs of compromise.


🔍 Key Differences Between CVE-2025-61882 and CVE-2025-61884

AspectCVE-2025-61882CVE-2025-61884
SeverityCritical (RCE)High (Unauthorized Access)
Attack VectorHTTP, Remote Code ExecutionHTTP, Configurator Runtime UI
Public ExploitsActively exploitedNo public exploit observed yet
MOS Note3106344.13107176.1
Additional MitigationIOC scanning, log monitoring, CPU baseline patchesRestrict access to Configurator UI, apply post-patch hardening

🛠️ Recommended Actions for EBS Administrators

  1. Immediately apply the patches for both CVEs as per Oracle’s MOS notes.

  2. Validate patch prerequisites (previous CPUs or required patch baselines).

  3. Restrict HTTP access to Configurator and BI Publisher components to trusted internal users only.

  4. Enable web application firewall (WAF) filtering for known exploit patterns.

  5. Perform threat hunting using HTTP access logs, BI Publisher logs, and concurrent manager trace files.

  6. Regularly monitor Oracle’s Security Alert portal and subscribe to their Critical Patch Update (CPU) notifications.


💡 Why This Matters

Many enterprises still rely on Oracle E-Business Suite for core ERP functions such as finance, supply chain, HR, and manufacturing.
Given its business-critical nature, EBS environments remain a prime target for cyberattacks, especially when exposed to the internet.

Applying the latest patches promptly and reviewing access controls can dramatically reduce risk exposure.
Organizations running EBS on Oracle Cloud Infrastructure (OCI) or private cloud should also ensure that network security lists and WAF rules are up to date.


🧠 Final Thoughts

The appearance of two major vulnerabilities in quick succession highlights the need for a proactive security posture in Oracle ERP environments.
Stay current with patches, monitor advisories, and collaborate closely with your DBA, Sysadmin, and InfoSec teams.

For more technical guidance, refer to:

  • CVE-2025-61882 – MOS Note 3106344.1

  • CVE-2025-61884 – MOS Note 3107176.1

Friday, September 12, 2025

How to Make a Linux User Password Never Expire: Step-by-Step Guide


Introduction:

Password expiry policies are important for security, but sometimes you need to keep certain Linux user accounts active without enforcing password changes. For instance, in administrative or automation accounts like user1, frequent password expiration can disrupt services. In this guide, we’ll show you how to make a Linux user password never expire.


Step 1: Check the Current Password Expiry

Use the chage command to see when a user’s password will expire:

sudo chage -l user1

Example output:

Last password change : Jul 03, 2025 Password expires : Sep 01, 2025 Password inactive : never Account expires : never Minimum number of days between password change : 1 Maximum number of days between password change : 60 Number of days of warning before password expires : 7


Here, the password is set to expire every 60 days.


Step 2: Make the Password Never Expire

Option 1: Using chage

sudo chage -M 99999 user1
  • -M 99999 sets the maximum days between password changes to effectively never expire.

Verify the change:

sudo chage -l user1

You should now see:

Password expires : never

Option 2: Using passwd

sudo passwd -x 99999 user1

Step 3: Verify the Configuration

Check again with:

sudo chage -l user1

Ensure:

  • Password expires: never

  • Account expires: never

This ensures the account will not require periodic password changes.


Step 4: Best Practices

  • Only disable password expiry for accounts that require uninterrupted access

  • Keep strong passwords or use SSH keys where possible.

  • Monitor accounts regularly to maintain security.


Conclusion

Preventing password expiration in Linux is simple using chage or passwd. By setting

odiuser or any critical account to never expire, you can avoid service disruptions

while maintaining control over other security policies.