This page is threadsafe.

What about your WordPress application?


How we can help

threadsafe.org is a Pressjitsu, Inc. project. We manage WordPress infrastructure for high-load and massively-concurrent applications. Over these past 6 years we have seen many tricky race condition vulnerabilities manifest in mission-critical code. We now offer our insight, toolsets and knowledgebase to provide the following services as part of the threadsafe.org platform:

Find

Critical section audits to locate the vulnerable parts in your WordPress application

Fix

Development, implementation and integration to handle and test (unit, load) potential race conditions

Prevent

Training your development team in crafting threadsafe WordPress code

Let's talk

Let's schedule a free 30-minute checkup and consultation call. No obligations or strings attached.

We'll never share your email with anyone else.

[A program that] contains a code sequence that can run concurrently with other code, and the code sequence requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence that is operating concurrently.

Race conditions can become a real danger when 2 or more users interact with unprotected parts of your WordPress application. Account balances, product quantities, counters and other mission critical data can become corrupted. They're hard to debug, fix and test.

Race condition vulnerabilities are not part of the OWASP Top 10; awareness is lacking. You may not even know there is a problem until it manifests itself often enough. Race conditions are attributed to cosmic rays, one-off glitches and voodoo curses.

By extension, neither are most of existing plugins, themes and custom code. All code is exposed, with very rare exceptions.

WordPress has at least 250 race condition bugs (many fixed, many still open)

WooCommerce has had at least 20 race condition bugs fixed, other issues remain unfixed.

2000+ plugins, themes affected - security-wise, performance-wise.

WordPress has no locking (synchronization) API. We use our own WP_Lock API when working with critical sections of code. This API is an open-source project that has helped hundreds of WordPress businesses.

We know how to test race conditions. It's not trivial.

This code contains a race condition:

$likes = get_post_meta( $post_id, 'likes', true );
update_post_meta( $post_id, 'likes', $likes + 1 );

Imagine two concurrent requests running: Request A and B. Request B lags behind a couple of milliseconds. But this is enough for it to retrieve a stale value from the database, as the value was not yet updated by Request A. The database contained 30 likes, both requests read the value, incremented it and saved 31 back into the database. Instead of two likes - one. What if these are votes? Or money?

This is a critical section of code that handles reading and writing data. Such sections should be protected with locks. Locks have to be tested for deadlocking, othewrise they risk locking up PHP workers indefinitely or for lengthy periods of time. This happens with PHP Sessions using flock(), for example.

A Pressjitsu, Inc. project / support@pressjitsu.com