Cornerstone error: /themes/index.php/style.css

Beta
#1

I was running into an error that came and went. After installing the latest Beta theme, the error is displayed on every page load. Please note that this is from a WPMU subfolder build.

Error:
Warning: file_exists(): open_basedir restriction in effect. File(/var/www/lmsurety.dev/htdocs/wp-content/themes/index.php/style.css) is not within the allowed path(s): (/var/www/:/usr/ share/php/:/tmp/:/var/run/nginx-cache/:/dev/urandom:/dev/shm:/var/lib/php/sessions/) in /var/www/lmsurety.dev/htdocs/wp-includes/class-wp-theme.php on line 299

I was debugging this with ChatGPT thinking it was a vibe coded plugin, but it wasn’t.

Here’s the comments from Chat:

• The error is generated by the active Pro theme (Theme.co/Cornerstone), not a plugin.
Culprit: themes/pro/framework/legacy/functions/updates/class-theme-updater.php:97

Its multisite updater uses scandir() and incorrectly passes themes/index.php to wp_get_theme(), which then checks index.php/style.css. The updater should filter entries using is_dir() before calling
wp_get_theme().

I strongly believe the warning originates in Pro’s multisite theme updater because its code deterministically reproduces the exact invalid path, while the MU and active-plugin searches found no
matching source.

Your findings:

  • The warning references themes/index.php/style.css.
  • themes/index.php is a normal file, not a theme directory.
  • The warning ultimately appears in WordPress core’s class-wp-theme.php, but core is only processing a bad theme name supplied by another caller.
  • Your priority was MU and network-active plugins.

My findings:

  • No MU plugin calls wp_get_theme(), constructs WP_Theme, enumerates the themes directory, or otherwise contains matching theme-loader logic.

  • Active/network-active plugins were searched separately.

  • Multisite Enhancements was the only plausible network-active candidate because it passes stored site stylesheet values to wp_get_theme().

  • Every site’s stylesheet option and the plugin’s cached blogs_themes transient were checked. None contained index.php.

  • Pro contains the exact faulty logic in themes/pro/framework/legacy/functions/updates/class-theme-updater.php:90:

      $theme_dirs = scandir( get_theme_root() );

  foreach ( (array) $theme_dirs as $theme_dir ) {
      $themes[] = wp_get_theme( $theme_dir );
  }

scandir() returns every directory entry, including the ordinary themes/index.php security file. Pro then executes:

wp_get_theme( 'index.php' );

WordPress interprets index.php as a theme directory and tests:

themes/index.php/style.css

That is precisely the path in your warning. The code is only selected on multisite:

  $themes = is_multisite()
      ? $this->multisite_get_themes()
      : wp_get_themes();

There is also a second bug: $themes[] produces numeric keys, while the caller later checks $themes[X_SLUG]. Therefore, the multisite updater may fail to recognize Pro even when no warning occurs.

Recommended repair
First, update Pro if Theme.co has released a corrected version. Otherwise, patch multisite_get_themes() to accept directories only and preserve the associative array expected by its caller:

  private function multisite_get_themes() {

      $themes     = array();
      $theme_root = get_theme_root();
      $theme_dirs = scandir( $theme_root );

      if ( false === $theme_dirs ) {
          return $themes;
      }

      foreach ( $theme_dirs as $theme_dir ) {
          $theme_path = trailingslashit( $theme_root ) . $theme_dir;

          if ( ! is_dir( $theme_path ) ) {
              continue;
          }

          $theme = wp_get_theme( $theme_dir, $theme_root );

          if ( $theme->exists() ) {
              $themes[ $theme->get_stylesheet() ] = $theme;
          }
      }

      return $themes;
  }

This is preferable to merely excluding index.php because it safely excludes every non-directory file, including future files placed in themes/. The associative key also repairs the updater’s lookup
logic.

Because this is vendor theme code, a Pro update may overwrite the patch. The durable solution is for Theme.co to incorporate it upstream; until then, apply it through your deployment process and
recheck it after every Pro update.

1 Like
#2

I’ll issue a fix in either a point release or in Pro 6.9. Have a great day.

1 Like