Needs better security features

  • Dan Knauss

    (@dpknauss)


    1 month, 2 weeks ago

    Nathan Ingram’s old post (“What does this do?”) raises an important security concern. Old, insecure plugin versions remain in web-accessible folders with only a “security by obscurity” hope that the random folder names can’t be guessed. This may be an unlikely attack vector, but it’s just not good to keep obsolete and insecure code around a long time.

    A “delete old versions” feature — globally and per plugin — would be helpful.

    Even better: allow Plugversions to be limited in scope to individual, admin-selected plugins rather than every plugin.

    Edited: Thanks to Jose for explaining the stored plugin versions are not usable as exploitable code or payloads that could be activated by an attacker who did not already have the ability to install and activate anything they want. It’s still a danger to keep old, insecure code around, however — the likely mishap would come from user error where an old, insecure version is rolled back into use. Coupled with a good security monitoring plugin/service, Plugversions is a really helpful maintenance tool — and it would be more helpful if the old versions could be easily purged, identified if insecure, and not automatically stored for every plugin with every update. A simple per-plugin opt-in like “Enable Versioning” would prevent wasted storage space and retention of unwanted old code.

    • This topic was modified 1 month ago by Dan Knauss. Reason: More information from the plugin owner
Viewing 2 replies - 1 through 2 (of 2 total)
  • Plugin Author Jose Mortellaro

    (@giuse)

    1 month, 1 week ago

    Thanks for the post. I want to clarify a core misunderstanding about how PlugVersions handles files, as the security model is fundamentally different from leaving unzipped code on a server:

    1. Zip Archives are Not Executable: PlugVersions stores old revisions as .zip files, never as extracted folders containing executable .php files. Even if an attacker knew the exact path, web servers cannot execute PHP code inside a compressed zip file.
    2. Cryptographically Secure Paths: The files reside in randomized directories generated with cryptographically secure strings. Guessing these paths is practically impossible via automated brute-forcing.

    Because of these two layers, storing these zip files does not expose your site to remote code execution risks.

    Regarding the suggested features: selectively enabling the plugin or adding manual delete buttons wouldn’t alter this core security model. If someone genuinely believes holding encrypted zip archives on a server is inherently unsafe, no amount of scoping or manual deletion toggles will solve that concern. The right choice for that threat model would simply be to not store local backups at all.

    We build PlugVersions for users who want lightweight, local rollback archives, but we completely respect that every admin has a different risk tolerance for their server stack.

    Thread Starter Dan Knauss

    (@dpknauss)

    1 month ago

    That’s great! Thank you for explaining.

Viewing 2 replies - 1 through 2 (of 2 total)

You must be logged in to reply to this review.