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 on equivalent profiles carrying *ALLOBJ and *SECADM special authority. It is one of the findings that has stayed on the list year after year, which tells you something about how hard it is to clear rather than how obscure it is.
The reason it persists is structural rather than careless. QSECOFR is IBM-supplied, ships on every system, and cannot be deleted. On a lot of machines it is also a shared account: several administrators know the password, some scripts and scheduled jobs reference it, and changing it means coordinating with everyone and everything that depends on it. So it does not get changed, and the longer that runs the more people have known it at some point.
QSECOFR is only the visible half. The quieter half is the set of equivalent profiles created during migrations, vendor installations, and integration projects, each carrying the same special authorities with far less scrutiny. Those passwords tend to be set once and never rotated, and in older shops you still find the legacy convention where the password is simply the profile name.
What turns this from a theoretical concern into a live finding is reachability. A powerful profile is available from every network route that accepts a sign-on, not just the green screen somebody pictures when they think about who can log in.
Why It Matters
A profile holding *ALLOBJ and *SECADM can read, change, or delete any object on the system and administer other users' authority. There is no object-level control that constrains it, because *ALLOBJ is specifically the authority that skips those checks. Reaching such a profile is close to owning the system outright.
The shared-account part causes a second problem that survives the incident. The audit journal records which profile acted, not which person was driving it. If four people know the QSECOFR password, the journal can tell you what happened and cannot tell you who did it, which is exactly the question asked afterwards. Segregation of duties fails on paper at the same time.
*SECADM adds a multiplier worth understanding. It can create and change user profiles, so anyone who reaches a *SECADM profile can manufacture more privileged profiles. That converts a single compromise into persistent access that survives resetting the password you think was the problem.
It is also a reliable audit failure in its own right. A shared administrative account with a static password fails control requirements under PCI DSS, SOX-driven reviews, and most regulated frameworks, on any platform. Auditors do not need to demonstrate that anything went wrong to write it up.
Recommended Actions
Force a password change on QSECOFR and every profile carrying *ALLOBJ or *SECADM, and confirm the new value is not derived from the profile name, the system name, or the previous password
Stop using QSECOFR as a working account. Move day-to-day administration to named, individually owned profiles so the audit journal records a person rather than a role
Set QPWDEXPITV so powerful profiles rotate on a schedule, and move QPWDLVL to 2 or 3 if you are still limited to ten character passwords
Set QMAXSIGN and QMAXSGNACN so repeated failed sign-on attempts disable the profile or device instead of allowing unlimited attempts
Set QLMTSECOFR so profiles holding *ALLOBJ and *SERVICE can only sign on at devices you nominated, rather than anywhere on the network
Put MFA in front of every sign-on route that can reach a powerful profile, including ODBC and FTP, not only the 5250 session
Keep the QSECOFR password retrievable under a documented break-glass procedure, and treat its sign-on as an alert to investigate rather than a line in a log
Audit service, vendor, and integration accounts in the same pass, because they carry the same authority with the least attention on them
Authority reviews on IBM i systems routinely find *ALLOBJ special authority sitting on application and business-user profiles that have no need for it. The count is usually a surprise: shops that expect to find three or four holders find dozens, and frequently nobody currently employed can explain half of them.
Nobody decides to do this. It arrives one reasonable decision at a time, through four routes that account for most of what you will find. Authority granted to a group profile flows to every member, including members added years later for unrelated reasons, and supplemental groups mean a profile can inherit from several at once. Creating a new profile by copying an existing one is fast and copies the special authorities along with everything else, so a single over-privileged template quietly reproduces itself across a department. Somebody elevates a profile at three in the morning to clear a production problem and never removes it, because removing it has no deadline and no owner. And vendor installers and integration projects ask for *ALLOBJ because it is easier than working out what the software actually needs, after which that profile runs unattended for years.
The reason it survives is that nothing breaks. An over-authorized profile works perfectly. There is no error message, no failed job, no user complaint, and no alert. Excess authority is invisible from the outside, which means the only way you will ever find it is by deliberately going to look.
Why It Matters
*ALLOBJ bypasses object-level authority checking entirely. Every profile holding it is a superuser for data access purposes whether or not anyone intended that, and no amount of careful object-level work constrains it.
That is what makes it more serious than it first sounds: it quietly cancels the controls you believe you have. Your *PUBLIC settings, your library authority, and the object-level grants somebody spent a month getting right are all decorative for those profiles. Combine that with the open network routes most systems still have, and the data can leave through ODBC or FTP without ever passing through an application that might have logged it.
It also fails segregation of duties on its face. An application profile holding *ALLOBJ can read payroll and change the general ledger. Whether anyone did is beside the point for an auditor, and it should be beside the point for you: the control either constrains access or it does not.
The encouraging part is that the correct alternative is native and free. Adopted authority lets a program run under the authority of its owner, giving users exactly the access that program needs without granting anything to their own profile. Most standing *ALLOBJ grants exist because nobody had time to scope one program properly.
Recommended Actions
Inventory every profile holding *ALLOBJ with PRTUSRPRF or an authority report, and resolve group and supplemental group inheritance rather than reading direct grants only
Run Authority Collection (STRAUTCOL, available from IBM i 7.3) to record the authority profiles actually use, so you can revoke a grant against evidence instead of hoping
Reconcile the list against real administrative roles and treat every surviving grant as an exception with a named owner and a written reason
Replace ad hoc grants with adopted authority scoped to specific programs, which is the native answer and costs nothing
Check profiles that were created by copying a template, since special authorities travel with the copy and multiply quietly
Review vendor, service, and integration accounts specifically, because they hold the same authority with the least scrutiny and the longest uptime
Include *SECURITY in QAUDLVL so future authority and profile changes are recorded from now on
Put the review on a recurring schedule with an owner's name against it, because authority creeps back within a year or two of any one-time cleanup
IBM i network server exit points, covering FTP, ODBC, JDBC, DDM, remote command and others, ship with nothing registered on them. Object authority still applies, so this is not an open door, but without an exit program or a network security product there is no granular control over who uses those routes and no log worth reviewing afterwards.
An exit point is simply a defined place where the operating system will call a program of yours before it allows a server request to proceed, giving you the chance to inspect it, permit or refuse it, and record it. IBM provides the hook on every relevant server. What IBM does not provide is the program, so on a default system the hook exists and is empty.
Menu security is what made this into a widespread exposure rather than a technicality. For years, restricting a user to an initial menu and setting LMTCPB(*YES) genuinely was a boundary, because a green screen was the only way onto the machine. That stopped being true a long time ago. ODBC, JDBC, FTP, DDM, remote command and Access Client Solutions all reach the data without ever loading a menu.
The practical version on a modern system: reporting tools and spreadsheets connecting straight to the database, integration jobs moving files over DDM, transfers running over FTP, and all of it authorized by object authority alone with little or no record that anyone reviews.
Why It Matters
A user with object authority to query a file interactively can usually pull that same file through ODBC or FTP. That bypasses application-level and menu-based controls completely, and typically produces no log entry anybody looks at. The authority model is being honoured exactly as configured, which is the uncomfortable part: nothing is malfunctioning.
The missing log is the half that hurts later. You cannot investigate what was never recorded. When a question does arrive, whether from an auditor, a customer, or an incident, the absence of exit point logging is what turns a question you could have answered in an hour into one you cannot answer at all.
This finding also compounds with the other two that assessments keep reporting. Excessive *ALLOBJ gives a profile access to everything, default or shared passwords make that profile reachable, and an unlogged network route is how the data actually leaves. Any one of the three is a finding. Together they are a working method, which is why they should be read as one problem rather than three.
One honest caveat about sequencing. Exit point control is the single change most likely to break a legitimate integration, because you will discover dependencies nobody documented. That is an argument for a monitoring phase before an enforcement phase, not an argument for leaving it alone.
Recommended Actions
Inventory which network servers are genuinely in use, covering FTP, the host servers behind ODBC and JDBC, DDM and DRDA, and remote command, before deciding what to restrict
Register exit programs on those exit points, or deploy an exit point control product rather than writing and then maintaining your own indefinitely
Run in monitor-only mode first and review what real users and integrations actually do, so enforcement does not break month-end processing
Read the exit point logs on a schedule. Configuring logging once and never reviewing it produces compliance without producing security
Restrict remote command and DDM to named administrators and specific service accounts, not to groups that happen to include them
Close or disable servers you are not using at all, since an unused server is far easier to switch off than to police
Forward exit point activity to your SIEM so network access to IBM i is reviewed alongside everything else rather than in isolation
Re-check after every operating system upgrade and after any new integration project, because a new project will cheerfully open a route you closed last year
The Integrated File System can be mapped as a network share and accessed like any other Windows file share. Ransomware that compromises a Windows endpoint holding a mapped IFS share encrypts the content of that share exactly as it encrypts local files, and it never runs natively on IBM i at any point.
That last detail is why the platform's reputation works against you here. It is broadly true that IBM i does not catch Windows malware, because the malware cannot execute on it. It is also completely irrelevant to this exposure. The malware does not need to run on the machine. It needs write access to files over SMB, which is precisely what a mapped drive provides, and the operating system's integrity has nothing to do with it.
People also underestimate what is actually sitting in the IFS, because decades of thinking in libraries does not transfer. Depending on the shop it holds save files, spooled output archives, documents, web server content, integration staging directories, and reports. On a meaningful number of systems it also holds backups.
The mapping itself is usually the weakest part. A drive letter mapped automatically at logon, pointed at a broad directory or the root, using a profile with wide IFS authority, on a workstation that also reads email and browses the web. Every one of those decisions was made for convenience and none of them were reviewed together.
Why It Matters
This is an observed attack route rather than a theoretical one. IBM i is not infected and does not need to be. The data is encrypted and held anyway, which is the only part that matters to the business asking when it can trade again.
The cruel version is what happens to recovery. If save files live in the IFS, and the IFS is reachable from the compromised endpoint, then the ransomware can reach your recovery as well as your production data. That single overlap is what turns a contained incident into a genuine crisis, and it is common precisely because putting save files in the IFS is convenient.
Detection is weak by default too. Thousands of IFS objects being rewritten over SMB in ten minutes looks like ordinary file activity from the system's point of view. There is no native alert waiting to tell you that mass encryption is in progress, so unless something is specifically watching for that behaviour, the first notification is a person saying the files look strange.
Authority is the control that actually constrains this, and it is the one most often skipped in the IFS. *PUBLIC on an IFS directory deserves exactly the scrutiny *PUBLIC on a production library deserves. Ransomware can only encrypt what the compromised account was allowed to write.
Recommended Actions
Inventory which IFS directories are shared and which Windows accounts and machines are able to map them, then reconcile that against who genuinely needs the access
Remove broad always-on mappings and scope each share to a specific directory rather than the root, using a specific account rather than a general one
Apply object authority to IFS directories with the same rigour used on libraries, *PUBLIC included, since that is what bounds the damage
Confirm save files are not sitting in a shared IFS directory, because that is the overlap that puts production data and its recovery behind the same compromised account
Keep offline or immutable copies of critical IFS content, reachable only by a route the ransomware on a workstation cannot traverse
Deploy IFS-aware anti-ransomware or file integrity monitoring that watches for mass encryption behaviour rather than for known signatures
Alert on unusual volumes of IFS object change as it happens, rather than discovering the pattern in a log afterwards
Test a restore of IFS content. An untested backup is a plan, and what you need during an incident is a demonstrated capability
A large number of IBM i shops still run production libraries with *PUBLIC authority set to *CHANGE or higher, at the library level, the object level, or both. In almost every case this is a legacy default rather than a decision anyone made, which is why asking who approved it tends to produce blank looks.
The mechanism behind it is the QCRTAUT system value, which sets the default public authority applied to newly created objects. On plenty of systems it is still sitting at *CHANGE, so every object created inherits permissive public authority at the moment it is created. Nobody grants this access. The system hands it out quietly on your behalf, and it has been doing so for as long as the value has been set that way.
There are two layers to check and people routinely check only one. Library-level *PUBLIC governs access to the library, and each object inside carries its own *PUBLIC setting. A carefully restricted library full of permissive objects is common, and so is the reverse, so a clean answer at one layer tells you very little about the other.
It survives for the same reason excess authority survives: nothing breaks. A permissive setting produces no error and no complaint. Worse, tightening it is the single change most likely to break a working integration, so it gets deferred, and deferring it has no cost until the day it does.
Why It Matters
*PUBLIC *CHANGE means any profile without a more specific authority can update or delete data in that library. Not read it. Change it and delete it. That distinction is the whole finding.
What makes *PUBLIC more consequential than it looks is the order IBM i checks authority in. It looks at the user's own authority, then the authority of the groups the user belongs to, and then *PUBLIC. So *PUBLIC is the floor applied to everyone you did not explicitly handle, and on a real production system that is most profiles, including ones created after whoever designed the authority model left.
Put that together with the network routes most systems still leave open and it becomes the most common route to unauthorized data modification that assessments actually find. The user carefully restricted to three menu options can update the same file directly through ODBC, because the menu was never the control and *PUBLIC *CHANGE was.
This one also differs from the rest of the list in kind, not just degree. The other findings are mostly about data being read. This one is about data being changed, and silent modification is considerably harder to detect and to unwind than a copy being taken. You can often prove what was read. Proving what a wrong value used to be, months later, is a different exercise.
Recommended Actions
Inventory *PUBLIC authority at both the library level and the object level, since a restricted library full of permissive objects is a common and easily missed combination
Check QCRTAUT, because it sets the default public authority for newly created objects and is frequently still at *CHANGE
Change QCRTAUT as well as the existing objects, otherwise tomorrow's objects arrive carrying the old default and you repeat the cleanup
Move toward *PUBLIC *EXCLUDE, or *USE where read access is genuinely required, with explicit group-profile grants covering the access people actually need
Use adopted authority in application programs rather than broad *PUBLIC grants, so the program carries the access instead of everyone on the system
Run Authority Collection first to see which profiles actually exercise that access, so you tighten against evidence rather than against a guess
Test in a non-production environment before enforcing. This is the change most likely to break an existing integration, and the breakage is usually a batch job nobody remembered
Re-check after restores and migrations, because restored objects can bring their original authority settings with them and quietly undo the work