rg4w

Thank you for your quick reply and the link. We have backups, and hardening is well documented and straightforward.

Once restored, I’d like to *know* the entry point. I can update the site and hope for the best, but until we know what happened we’re just guessing.

Most WP exploits come from Core or plugins not being updated, and I’d guess that’s what we have here. I can go through all the relevant CVEs, but that seems like the sort of thing that can be assisted with automation, so knowing about any WP-specific tools for forensics beyond the reporting in things like WordFence would be especially helpful.

So far one of the better resources I’ve found on WP forensics is:
https://wpsecurityninja.com/wordpress-vulnerabilities-database/#4_Vulnerability_Assessment_Management

I’ll continue seeking until I either know the entry point or know with confidence that I’ve exhausted all reasonable options to find it. I’ll report back any other useful info I come across to this thread.

Thanks again to everyone who’s contributed here, esp. Chip Bennett (I actually read all of the comments at the post you linked to – very interesting discussion).

After further reading around the Web I’ve come to see a possibility for clarifying WP’s License page which may put this issue to rest:

It seems it’s a common practice among theme devs and some plugin devs to use WP example code as a starting point for their work. In such cases, it’s not so much the names of WP functions being called that are the issue as the actual code blocks that use those functions which were originally written by the WP team.

In such cases, obviously any use of other people’s GPL code inherits the rights and responsibilities of the GPL, so no question there.

However, if a plugin is written entirely from scratch, so that it includes no code from WP per se but merely calls API functions that are defined in WP, then the situation is very much like applications written for Linux, which make calls to the kernel but do not include kernel code.

The most common interpretation of making function calls in the FOSS world holds that merely calling APIs does not constitute “derivative work”, and if the WP License page were augmented to clarify that this issue may well go away.

If instead the official stance of WP’s counsel were that even just making function calls to the API constitutes “derivative work”, much of the FOSS community, and chiefly desktop Linux, may find itself at risk:

Desktop Linux is a viable option in part because of the support of third parties who write proprietary code for the platform. Regardless of whatever preference we may have for truly free-as-in-freedom code, we accept that the support of companies like AMD, IBM, Intel, NVidia, Google, Valve, and others helps provide a healthy ecosystem of drivers and applications that range from enjoyable to essential.

Even on the server, Linux sometimes benefits from proprietary code, such as some Oracle database drivers.

If a court were to favor the position that merely using an API constitutes “derivative work”, many third parties not in a position to license their code under the GPL would be forced to abandon Linux.

There may also be a corollary issue affecting FOSS apps on Mac and Windows, in which questions are raised about whether GPL’d apps can be compiled with API calls to non-free OSes without invalidating their own GPL license, as they would no longer be seen as comprised of completely free code.

Given their clearly-stated preference for truly free code I’m assuming that everyone on the WP and Drupal teams use Linux, and I’m also among the many millions who rely on Linux in our businesses. So with this uncommonly broad interpretation of API use as “derivative work”, whether or not we pursue development of WP plugins I and millions of others still very much have a horse in this race.

So in short, I believe it may be useful for GPL-governed projects to reach a common interpretation of whether API use constitues “derivative work”, and for the sake of a useful GNU Linux I would favor an interpretation that they do not.

If the WP and Drupal teams were to amend their license pages to draw a clear line between including GPL’d example code (which would inherit GPL responsibilities) and merely making API calls within original code (which would not), the benefits would be many:

– WP and Drupal third-party devs would have clarity about which types of use would require GPL licensing.

– WP and Drupal end-users could select third-party components with confidence that they either reflect their preference for truly-free code, or at least are not just one lawsuit away from having a favorite proprietary plugin pulled out from under them.

– WP and Drupal’s apparent position with regard to API use would no longer pose a threat to the Linux community, bringing a greater consistency to GPL interpretation across nearly all FOSS projects.

Of course all of this is predicated on my understanding that it’s the API use that is the central issue here. If that understanding is incorrect I would appreciate any clarification on what the central issue actually is.

Thanks in advance for considering this.

Honestly, unless you talk to a lawyer that knows their way around copyright and licencing, any advice that you get on here is pretty much conjecture and cannot be taken to be anywhere near legal or binding.

Understood. I was hoping for a link to something from WP,org’s counsel. Ending conjecture would seem to be in the interest of the entire community.