Oracle E-Business Suite and Fusion Security Guide: Patching, Access and Exposure

Oracle E-Business Suite runs finance, procurement, payroll and supply chain for thousands of organisations, and when it is reachable from the internet and behind on patches, a single unauthenticated HTTP request can hand an attacker the whole ledger. In 2025 the Cl0p extortion group showed this at scale, exploiting an E-Business Suite zero-day and then emailing executives to demand payment for stolen data. This guide covers both estates that carry the Oracle applications name: on-premises or hosted E-Business Suite (EBS) 12.2, which you patch and harden yourself, and Oracle Fusion Cloud Applications, where Oracle runs the platform and your job is roles, sign-on and integrations. It explains how identity works in each, which accounts and roles are privileged, how to treat integration and system accounts as non-human identities, what to log and how to build a hardening baseline. It is written for EBS and Fusion security administrators, DBAs, ERP application owners and the security engineers who support them.

Key takeaways

• Patch cadence is now monthly as well as quarterly. Oracle still ships cumulative Critical Patch Updates on the third Tuesday of January, April, July and October, and since May 2026 also publishes monthly Critical Security Patch Updates for high-priority fixes, plus out-of-band Security Alerts.
• Internet exposure is the deciding risk. Four EBS vulnerabilities are in the CISA Known Exploited Vulnerabilities catalogue, all exploitable over HTTP without authentication, and three are flagged as used in ransomware campaigns.
• EBS has default accounts you must fix. SYSADMIN, GUEST and a list of seeded application users ship with known or default passwords; Oracle's fnddefpw.sql script finds the ones still unchanged.
• Fusion security is role design. Predefined job roles grant broad access; Oracle's own guidance is to copy and trim them, not assign them as delivered, and to remove setup roles such as Application Implementation Consultant once implementation ends.
• The busiest identities are not people. The APPS schema, the GUEST account, concurrent manager users and Fusion integration users move more data than any employee, and they rarely appear in access reviews.

How identity and access work in Oracle E-Business Suite and Fusion

The two products share a vendor and a business purpose, but their security models and their division of responsibility are different.

E-Business Suite access model

• Function security: the base layer. It restricts which menus, menu options and page components a responsibility exposes, not the data behind them.
• Data security: controls which records a user can see or act on, for applications written to the Data Security Framework.
• Role based access control: roles bundle responsibilities, permissions and policies for a job, can inherit subordinate roles, and change every holder's access when the role changes.
• Delegated administration: local administrators manage a subset of users and roles through User, Role and Organization Administration Privileges, defined as data security policies. Actions such as Create Role, Assign Role and Run Security Wizard can be granted individually.
• Proxy users: a delegator can grant a delegate specific responsibilities instead of sharing a password, and the Security Administrator decides which responsibilities can never be delegated.

One detail matters for governance: Oracle documents that directly assigning a role bypasses Oracle Approval Management routing rules, so an administrator assignment skips the approval chain a self-service request would follow.

Fusion access model

• Job roles: represent jobs, such as General Accountant. Assigned to users.
• Abstract roles: represent people regardless of job, such as Project Team Member. Assigned to users.
• Duty roles: collections of function security privileges inherited by job and abstract roles. Never assigned directly.
• Aggregate privileges: predefined bundles of a function privilege and its data security policies; they cannot be created or modified, only included in roles.

See the Segregation of Duties Guide for the conflict rules that ERP role design should enforce.

Admin roles and privileged access

In both products privilege is spread across accounts, responsibilities and roles rather than one switch. Treat everything in this table as privileged.

• Copy, do not assign: Oracle's Fusion guidance says assigning predefined roles as delivered gives users full access to data and functions without demonstrated need. Copy the role, remove unneeded privileges and use Compare Roles after each quarterly update.
• Local login back door in EBS: even with SSO, local users can sign in at /OA_HTML/AppsLocalLogin.jsp. Keep local passwords only for break-glass administrators and alert on their use. See the Break-Glass Account Guide.
• Separate duties: the person who creates suppliers or changes bank details should not approve payments, and the person who grants a responsibility should not be its holder.

See the Privileged Access Management Guide.

Integrations, API tokens and service accounts

ERP is wired into banks, payroll providers, data warehouses and procurement networks. Each connection runs as a non-human identity, and in EBS several of them are built in.

Non-human identities in E-Business Suite

• GUEST: used by the application for unauthenticated pages. Oracle says do not disable it; its password must be upper case, and changing it means updating s_guest_pass in the context file and running AutoConfig.
• Seeded application users: accounts such as ASGADM, ASGUEST, IBE_ADMIN, IBE_GUEST, XML_USER, AUTOINSTALL and WIZARD should have passwords changed and be end-dated unless the product that needs them is in use. ANONYMOUS, CONCURRENT MANAGER, FEEDER SYSTEM and INITIAL SETUP ship end-dated; keep them that way.
• Concurrent manager operator: Oracle documents a user such as CONCOPER with the Concurrent Manager Operator responsibility, configured through s_cp_user and related context variables, so managers can be started with adstrtal.sh -secureapps without typing the APPS password.
• Concurrent program credentials: Oracle offers ENCRYPT (pass credentials through the FCP_LOGIN environment variable) or SECURE (pass no credentials) execution options; use them instead of plain credentials on the command line.
• DBC files: hold the application's database connection details. Create them with AdminDesktop, make them IP-specific and set permissions to 600.
• Server security: set s_appserverid_authentication to SECURE so only registered application servers can connect.

Non-human identities in Fusion

Fusion integrations (REST and SOAP services, file-based data import, Oracle Integration Cloud flows and third-party connectors) authenticate as Fusion users holding roles, through the identity domain. Treat each as an integration account: one per integration, a custom role with only the duty roles it needs, no interactive sign-on where the identity platform allows it, an owner of record and a rotation date for its password, client secret or certificate. Oracle's Security Console also manages certificates used for integrations.

See the Service Account Security Guide and the Secrets Management Guide.

Patching and internet exposure

For EBS, patching and exposure are the controls that decided the 2025 outcome. Oracle's release model now has three channels.

Known exploited EBS vulnerabilities

The Oracle E-Business Suite Cl0p campaign of 2025 combined the CVE-2025-61882 zero-day with extortion emails sent from compromised mailboxes. Oracle's alert published indicators including a reverse shell pattern and two source IP addresses, and noted that its prerequisite was a CPU two years old: customers who had fallen two years behind could not apply the emergency fix without first catching up. See the Data Extortion Without Encryption Guide.

• Keep EBS off the internet by default: if modules such as iSupplier or iRecruitment must face external users, follow Oracle's DMZ configuration note (KA1036). Only the products it lists are certified for external use. Set NODE_TRUST_LEVEL to 3 (External) on DMZ nodes and use responsibility trust levels so external servers cannot reach internal responsibilities.
• Stay on a supported release: Oracle provides patches only for versions in Premier or Extended Support.
• Patch database and middleware too: the May 2026 CSPU advisory notes EBS exposure depends on the Database and Fusion Middleware versions in use.

See the Patch Management Guide and the Zero-Day and Exploited Vulnerabilities Guide.

Logging and detection

Mapped to MITRE ATT&CK, the main techniques are Exploit Public-Facing Application (T1190), Web Shell (T1505.003), Valid Accounts (T1078), Account Manipulation (T1098), Data from Information Repositories (T1213) and Exfiltration Over Web Service (T1567). Retain sign-on data beyond the 400-day default of the Purge Sign-On Audit Data program (FNDSCPRG) by forwarding it to a SIEM. See the SIEM Guide.

Metrics

• Patch lag: days between each CPU, CSPU or Security Alert release and production deployment; target under 30 days, and under 72 hours for KEV entries.
• Secure Configuration Console status: number of Severity 1 checks failing or muted.
• Default passwords: count of accounts returned by fnddefpw.sql (target zero).
• Privileged population: holders of SYSADMIN-level responsibilities, Security Administrator and IT Security Manager, trended monthly.
• Integration ownership: percentage of integration and seeded accounts with a named owner and rotation date.

Hardening baseline

The EBS settings below come from Oracle's E-Business Suite Security Guide. The Secure Configuration Console, reached through Functional Administrator then Configuration Manager, checks most of them and, after the latest ATG_PF Release Update Pack, puts the instance into locked-down mode until an administrator resolves or acknowledges the checks.

Rollout

1. Inventory and exposure: list every EBS node, its release, its CPU level and whether it is reachable from the internet. Remove internet exposure that is not certified in KA1036.
2. Catch up on patches: bring production to the current CPU and CSPU level in a cloned test instance first, with regression testing of month-end processes. Keep the pre-patch backup for rollback.
3. Fix accounts: run fnddefpw.sql, change defaults, end-date unused seeded users and rotate APPS and WebLogic passwords.
4. Apply profiles in a clone: run the Secure Configuration Console and the AdminSecurityCfg utility with -check, fix in test, then promote. Mute only checks that genuinely do not apply, with a recorded reason.
5. Turn on logging: set Sign-On:Audit Level to Form, enable Page Access Tracking and Audit Trail for security tables, forward to the SIEM.
6. Fusion roles: run the User and Role Access Audit Report, replace predefined role assignments with trimmed copies, remove Application Implementation Consultant from post-go-live users.
7. Review quarterly: after each Fusion update and each CPU, recheck console status, privileged holders and integration accounts.

Small versus large estates: a single-instance EBS shop can patch on each CPU and treat CSPUs as triggers only when they touch modules in use; a large multi-instance estate should automate CPU level reporting and run a standing monthly patch window.

Common misconfigurations

• Internet-facing EBS on an old CPU: the pattern behind the 2025 Cl0p campaign. A two-year-old prerequisite turned an emergency patch into a project.
• Default passwords on seeded accounts: GUEST, ASGUEST or IBE_GUEST left at defaults on an external node give attackers a valid session.
• Diagnostics left on: FND_DIAGNOSTICS or the developer console enabled in production leak verbose errors and internal detail.
• WF_ADMIN_ROLE set to *: makes every user a workflow administrator.
• Predefined Fusion roles assigned as delivered: implementation consultants and power users keep broad access long after go-live.
• APPS password in scripts and clones: the same credential reused across production, test copies and custom jobs, never rotated.

Framework mapping

Practitioner checklist

• Record every EBS instance's release, CPU and CSPU level and internet exposure; confirm KEV-listed EBS CVEs are fixed.
• Subscribe to Oracle's CPU, CSPU and Security Alert announcements and set patch deadlines per channel.
• Run fnddefpw.sql and end-date every seeded account not in use; change SYSADMIN, GUEST, APPS and WebLogic passwords.
• Clear Severity 1 checks in the Secure Configuration Console and document every muted check.
• Restrict AppsLocalLogin.jsp to break-glass administrators where SSO is in place.
• Set Sign-On:Audit Level to Form and ship sign-on, Audit Trail and web tier logs to the SIEM.
• Replace predefined Fusion role assignments with trimmed copies and remove Application Implementation Consultant after go-live.
• Give every integration and concurrent account an owner, a scoped role and a rotation date.
• Mask data and change all passwords in every clone.

Standards and references

• Oracle: Critical Patch Updates, Security Alerts and Bulletins
• Oracle: Security Alert CVE-2025-61882
• Oracle: Critical Security Patch Update Advisory, May 2026
• Oracle: E-Business Suite Security Guide, Oracle E-Business Suite Security
• Oracle: E-Business Suite Security Guide, Secure Configuration Console
• Oracle: Fusion Cloud Securing Applications, Guidance for Assigning Predefined Roles
• CISA: Known Exploited Vulnerabilities Catalog
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: SAP Identity and Access Security Guide · Oracle Cloud Infrastructure Security Guide · Attack Surface Management Guide · Database Security Guide