These are not single-incident CVEs. They are recurring, well-documented vulnerability classes found repeatedly across live IBM i systems in industry security assessments, most notably Fortra's annual State of IBM i Security Study.
Industry surveys of live IBM i shops, including Fortra's annual State of IBM i Security Study, have repeatedly found a meaningful share of systems with default or weak passwords still active on QSECOFR or equivalent *ALLOBJ/*SECADM-authority profiles.
Why It Matters
A profile with *ALLOBJ and *SECADM special authorities can read, change, or delete anything on the system and administer other users' authority. A weak or default password on such a profile is close to a complete compromise if reached.
Recommended Actions
Force a password change on QSECOFR and any other profile carrying *ALLOBJ or *SECADM special authority
Set QPWDEXPITV and related system values to enforce regular password rotation on powerful profiles
Move day-to-day administration to named, individually-owned profiles rather than shared use of QSECOFR
Add MFA in front of any sign-on path that can reach a powerful profile
Authority reviews on IBM i systems commonly find *ALLOBJ special authority granted to application and business-user profiles that do not need it, usually inherited from a group profile or carried over from an old troubleshooting grant that was never revoked.
Why It Matters
*ALLOBJ bypasses object-level authority checks entirely. Every profile holding it is effectively a superuser for data access purposes, whether or not that was the intent, which directly undermines segregation-of-duties and audit requirements.
Recommended Actions
Run an authority collection (STRAUTCOL) or equivalent report to inventory every profile holding *ALLOBJ
Reconcile the list against actual administrative role requirements and revoke unnecessary grants
Replace ad hoc *ALLOBJ grants with adopted authority (profile swapping) scoped to specific programs where elevated access is genuinely needed
Re-run the authority review on a recurring schedule, not as a one-time cleanup
IBM i network server exit points (FTP, ODBC, JDBC, DDM, remote command) ship without restrictions by default. Object-level authority still applies, but without exit-point programs or a network security product, there is no logging or granular control over who is using these access paths and how.
Why It Matters
A user with object authority to run queries interactively can typically pull the same data through ODBC or FTP, bypassing menu-based or application-level controls entirely and often without producing a log trail administrators would notice.
Recommended Actions
Register exit point programs on FTP, ODBC, JDBC, DDM, and remote command server exit points, or deploy a network security / exit point control product
Log and review exit point activity, not just configure it once and forget it
Restrict remote command and DDM access to service accounts and named administrators only
Test exit point rules against real user activity before enforcing in blocking mode to avoid breaking legitimate integrations
The Integrated File System (IFS) can be mapped as a network share and accessed like any Windows file share. Ransomware that compromises a Windows endpoint with a mapped IFS share can encrypt IFS content the same way it encrypts local files, even though the ransomware itself never runs natively on IBM i.
Why It Matters
This is a real, observed attack path, not a theoretical one: IBM i itself is not directly infected, but IFS-stored data (including save files, documents, and integration staging areas) can still be encrypted and held for ransom through a compromised Windows client.
Recommended Actions
Restrict which Windows accounts and machines can map IFS shares, and avoid broad, always-on mappings
Deploy IFS-aware anti-ransomware or file integrity monitoring that watches for mass encryption behavior
Keep offline or immutable backups of critical IFS content, separate from the same network path that ransomware would traverse
Apply object authority restrictions on IFS directories the same way you would on library-based objects
Many IBM i shops still run production libraries with *PUBLIC authority set to *CHANGE (or higher) at the library or object level, a legacy default from earlier system setup practices rather than a deliberate access-control decision.
Why It Matters
*PUBLIC *CHANGE means any profile without an explicit, more restrictive authority can update or delete data in that library by default. Combined with broad ODBC/FTP access, this is one of the most common paths to unauthorized data modification found in IBM i security assessments.
Recommended Actions
Inventory *PUBLIC authority settings on production libraries and files
Move toward *PUBLIC *EXCLUDE or *USE with explicit group-profile grants for the access levels actually required
Use adopted authority in application programs rather than broad *PUBLIC grants to give users the access they need
Test authority changes in a non-production environment first; tightening *PUBLIC authority is the change most likely to break an existing integration if done without testing