All-In-One Security Plugin Patches Sensitive Data Exposure Vulnerability in Version 5.2.0

All-In-One Security (AIOS), a plugin active on more than a million WordPress sites, was found to be logging plaintext passwords from login attempts in the database and has patched the security issue in version 5.2.0.

In a post titled “Cleartext passwords written to aiowps_audit_log” published to the plugin’s support forum two weeks and five days ago, @c0ntr07 reported the issue:

I was absolutely shocked that a security plugin is making such a basic security 101 error (not to mention being out of compliance with NIST 800-63-3, ISO27000, CIS, HIPAA, GDPR, ….)

How can I stop the logging of clear text passwords?

How can this be fixed so we don’t fail the upcoming security review and audit by our third-party compliance auditors?

A support representative from AIOS confirmed that it was a known bug in the last release and offered a development copy of a zip file with a fix. It took more than two weeks for the patch to be published.

In version 5.2.0, released on July 10, 2023, AIOS included the following security updates in the plugin’s changelog:

  • SECURITY: Remove authentication data from the stacktrace before saving to the database
  • SECURITY: Set tighter restrictions on what subsite admins can do in a multisite.

Users are advised to update to version 5.2.0+ immediately in order to secure their sites. At the time of publishing, almost no users have updated to 5.2.0+, leaving hundreds of thousands of users who are running 5.1.9 still vulnerable.

“So far the developer haven’t even told the users to change all passwords,” Patchstack CEO Oliver Sild said in response to the issue on Twitter. “Due to the scale, we will 100% see hackers harvest the credentials from the logs of compromised sites that run (or has run) this plugin.

“We have also sent out vulnerability alert to all Patchstack users. Hopefully the Updraft team will do the same and will tell their security plugin users to clean those logs ASAP and ask all the site users to change the passwords where ever they used the same combinations.”


25 responses to “All-In-One Security Plugin Patches Sensitive Data Exposure Vulnerability in Version 5.2.0”

  1. Not sure what happened to the formatting of my first attempt…. here goes again….

    Sincere apologies to all AIOS users for this bug.
    The above piece omits to note that the passwords are exposed only to someone who can read a copy of the WordPress database, which means, a WordPress admin (or on a multisite install, the admin of a site can see data for their own site (not other sites)).

    “and will tell their security plugin users to clean those logs ASAP”

    There’s no need to do that – if you’re running the current version of AIOS, then it wiped them upon update. The release took longer than we hoped to get out because of testing back-and-forth on the update task.

    “Due to the scale, we will 100% see hackers harvest the credentials from the logs of compromised sites that run (or has run) this plugin.”

    The WordPress security and journalism landscapes would be much improved if vendors of security products and journalists avoided hyperbolic inaccuracy, and stuck to accurate descriptions after verifying the actual situation before publishing. As per the above, in order to achieve this, the attacker would need admin-level access to harvest anything (i.e. the same level of access that would allow him to do anything that needs admin privileges on the site already), and the site owner would have to have not updated to the current AIOS release.

    i.e. It’s an “admin-only” vulnerability. These aren’t desirable, of course, and hence we are genuinely sorry to all our users for its existence. But if you have admins on your site who are hostile attackers, you also need to fix that situation too, as you’ll still be vulnerable to many other problems after updating AIOS (e.g. your hostile admin could add or remove plugins or users, export data, etc etc; and if they’re not on multisite a regular admin can do anything and everything, so it’s not a privilege escalation at all).

      • There is plenty of criticism that can be made about what happened here, but they were not intentionally storing the passwords in plain text and they are not saying that is okay.

        They were not even trying to store the passwords at all, they were storing the contents of the PHP function debug_backtrace() as part of logging.

        The biggest issue is the length of time they took to address this, not the original mistake.

        • Well the main issue is three fold:

          The time they took to address this issue, cause it was mentioned to them way before it went public.
          The reaction to the criticism, they are still unaware of how big of an issue this is and what kind of impact they make.
          The comments about “you need admin privilege” shows how few they know about real security while they do deliver a “security” plugin?

          I agree that the initial “mistake” can be forgiven and if it was solved right away (like WP Umbrella did btw) its more than forgiven. This response isn’t…

          • Hi,

            Please be assured that we are not trying to minimise the bug. It took longer that we’d hoped because of problems we encountered in the back-and-forth of testing the solution.
            The reason for mentioning that you need to be a logged-in admin to exploit it is because it is (rightly) standard practice to include the level of privilege needed for successful exploitation in security reports.

          • It doesn’t seems like they are trying to underplay the seriousness of the issue. But it does seems that others are interested in overstating the impact or haven’t fully checked over things before making overstated claims (like not realizing the logs were automatically wiped), which is a common problem.

            Based on our experience, noting the privileges needed would indicate someone that knows about real security. It is quite common for people claiming to have discovered vulnerabilities in WordPress plugins to not even know that they were only able to do something because they were logged an Administrator, which has explicit permission do what the vulnerability is supposed to allow.

            • So as an admin I cannot see the passwords for other users, and for a reason cause most users still use the same password for multiple things.

              Also any unauthorized access to the DB or code will give the hacker the passwords on a platter without any effort.

              So not sure where your coming from, but any form of storing passwords, secrets, keys, etc. As plain text is an amateur mistake.

  2. While we hope hostile or untrustworthy Admin users are uncommon, and AIOS users are enforcing appropriate user security policies, easy access to unencrypted account credentials is not a normal Admin privilege, and being an Admin is not the only way hackers get access to a database. That data may also remain in some backup archives and end up in cloned or migrated sites.

          • Someone would have to investigate if the ones from 2016 and backwards could do that, but none of the ones since then look like they’d have a chance of doing that.
            Again: this isn’t a defence of bugs (and the current owners didn’t own it most of that time), it’s because accuracy and precision matter in security reporting. Snicco in particular have based their marketing for their new products heavily on “we are a class above everyone else” and have invited everyone to judge them on that basis….

            • Almost no investigation is needed to discover that, yes, there have been vulnerabilities in the plugin in the past that would allow malicious database access. If you had simply clicked on the SQL injection listed there, Patchstack says “This could allow a malicious actor to directly interact with your database, including but not limited to stealing information.”

              You say your comment is because accuracy and precision matter in security reporting, not because you’re defending the bug. But you didn’t point out anything that was inaccurate, and instead provided your judgement of Snicco, which you say he invited based on his marketing of a product that isn’t mentioned anywhere in the article or in the comments.

              Like you, I also prefer accurate reporting, but as far as I can tell, the article was accurate, Dan’s comment was accurate, and Snicco’s reply was accurate. I can’t figure out what you’re objecting to, other than some of Snicco’s marketing that you’ve apparently seen elsewhere.

              • Based on our experience reviewing Patchstack’s claims, their claims of vulnerabilities and details of vulnerabilities are not always accurate. So it wouldn’t be accurate to say no investigation is needed.

                The listed SQL injection vulnerabilities are from 2015 and the logging at issue was introduced in May, so there was no overlap between the two. Bringing up 8 year old vulnerabilities and not noting how long ago they were found, seems rather misleading.

                • I don’t see anyone claiming that the vulnerabilities were overlapping. The claim was that admin access isn’t the only way hackers can get access to the database, and the SQL injection vulnerability from 2015 is a direct example of that.

    • An Administrator can do almost anything, so saying that access to unencrypted account credentials is not a normal Administrator privilege isn’t really true. If that was true, then then it wouldn’t be possible for this plugin to have been able to log them either.

      That isn’t to say that those should be logged, but security providers shouldn’t be acting as though Administrators don’t already have access beyond what an issue in plugin can provide them.


Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.