This occurred because Waindigo DataTables had custom code to use autolinks (detected as Other-type) in a way that was not supported by our existing autolink code, running multiple autolinkers simultaneously. We had not allowed this because it usually meant that an infinite loop was occurring. This was actually a bug in the DataTables add-on, as it was attempting to do something that was not allowed.
I have made changes to our code that now allows multiple autolinkers; if an infinite loop does occur, it would be a problem with the code that calls the autolinker and not the autolinker itself.
Additionally, the Waindigo DataTables add-on contains a security vulnerability, which should be addressed in a new release of that add-on (already fixed on your site). In
library/Waindigo/DataTables/Extend/XenForo/BbCode/Formatter/Base.php, find:
Code:
$rows[$rowId][$columnId] = $parser->render(htmlspecialchars_decode($column));
Replace with:
Code:
$rows[$rowId][$columnId] = $parser->render($column, array(
'allowHtml' => 1,
'inDataTable' => 1,
'plainChildren' => 0
) + $rendererStates);
In VaultWiki, the vulnerability breaks the permissions sandbox for wiki templates (potentially by decoding HTML that should not be decoded) or the permissions for wiki content in general within TABLE, by not honoring the rendererStates of the code that contains the TABLE. The vulnerability would generate insecure output for any add-on that expects $rendererStates to contain certain values related to permissions. If DataTables insists on calling ::render recursively here (something I have discouraged to them in the past), there is no reason for DataTables not to honor parent $rendererStates. And instead of always decoding, by setting the 'allowHtml' flag to 1 (as in my replacement code above), ::render will honor the existing HTML state already processed by ::renderSubTree. Please report this issue to the add-on author.
EDIT: My work on this issue should be complete now. I have finished cleaning up the errors in the log that were related to it.