Feature #16715

Pollution of linkvars, and resulting spammed cache, is a recurrent complaint.

Added by Christian Reiter about 13 years ago. Updated over 5 years ago.

Should have
Target version:
Start date:
Due date:
% Done:


PHP Version:
Sprint Focus:


It is possibie to call a multilanguage Typo3 page with a URL like


This is passed through as a linkvar and displayed in all typolinks.
If it happens that the cache had just been deleted, and is refreshed with this access, the spammed linkvars enter the cache.

It is a frequent phenomenon that spam robots go over pages and submit any and all detected parameter options with their message. Several instances have been documented in the newsgroups where people have had their websites flooded in this way, or have observed other websites with this problem.
This is not a hacking or XSS issue, as no code can be executed and the undesirable parameter is internally used as 0 (default language), however it leads to injection of URLs and messages into all links which is visible e.g. in the status bar and adress bar. This can be considered a form of defacement.

This affects all Linkvars

In practice almost all Linkvars are needed only as integers.

I propose a new configuration option, which enforces numeric linkvars. The point to implement this would be
class.tslib_pagegen.php in typo3/sysext/cms/tslib line 234 ff
taking into consideration also linkvar arrays.
So any non-numeric linkvar would always be put out as 0. For the vast majority of websites who use linkvars only for language parameters and similar things, this could be applied without losing any functionality.
(If special cases of linkvars need to be supported one could perhaps offer the option of adding a RegEx to be applied to linkvars)

See for instance


and posting from Nov.14 in typo3.german
(issue imported from #M4514)

Related issues

Related to Language Selection - Bug #8681: In combination with realurl it's possible to spam the realurl cache Resolved 2010-07-06


#1 Updated by Michael Stucki about 13 years ago

I'll take care of that.

#2 Updated by Popy no-lastname-given about 13 years ago

There's a begin of solution : $TYPO3_CONF_VARS['FE']['pageNotFoundOnCHashError'] = 1;

But the TSFE doesn't really checks the cHash validity :(

#3 Updated by Christian Reiter about 13 years ago

I used a very simple solution for this when I had the problem,
in my case I made the reduction to integer default since I only had integer linkvars.

in the class.tslib_pagegen.php firstly

$GLOBALS['TSFE']->linkVars = ''.$GLOBALS['TSFE']->config['config']['linkVars'];
if ($GLOBALS['TSFE']->linkVars) {
$linkVarArr = explode(',',$GLOBALS['TSFE']->linkVars);
while(list(,$val)=each($linkVarArr)) {
$GET = t3lib_div::_GET();
if ($val && isset($GET[$val])) {
if (!is_array($GET[$val])) {// CR: Almost anything can be added as linkvar and will be reoutput, what do we usually need?

if (!$GLOBALS['TSFE']->config['config']['allowNonNumericLinkVars']){$theValue=intval($theValue);}
} else {
$GLOBALS['TSFE']->linkVars.=t3lib_div::implodeArrayForUrl($val,$GET[$val]); // -> if using arrays as linkvars, have to deal with this

and in t3lib_div put a similar check in the function implodeArrayForUrl
Since implodeArrayForUrl is used in many places, not only for linkvars the updated function should not just check the config parameter,
instead there should be a new parameter passed to it in the function call such as "makeint" just as there already is a skipBlank and rawurlencodeParamName option
Otherwise maybe some things might be turned to integers that shouldn´t (from pibase or wherever...)

#5 Updated by Chris topher almost 8 years ago

  • Category deleted (Communication)
  • Target version deleted (0)
  • PHP Version deleted (4)

#6 Updated by Stanislas Rolland over 6 years ago

I wonder why this issue was closed. It seems to me that the issue can still be reproduced in TYPO3 6.1.

#7 Updated by Michael Stucki over 6 years ago

  • Status changed from Closed to New
  • Assignee deleted (Michael Stucki)

I agree with Stanislas, therefore I'm reopening the ticket.

#8 Updated by Christian Reiter over 5 years ago

Hasn't this been solved years ago when the option to control linkvars was added?

config.linkVars = L(0-20)


If just "config.linkVars = L" is used the described abuse is still possible but nowadays that would be considered a configuration error.

#9 Updated by Michael Stucki over 5 years ago

I agree that this can be circumvented with the example you mentioned. Still, it doesn't work out of the box. I am not sure if that will be possible, though...

#10 Updated by Christian Reiter over 5 years ago

I guess "out of the box" would mean that by default linkvars allow only integers, and anything else has to be explicitly allowed by configuration.
I wouldn't mind that but it could break existing configurations that use other kinds of linkvars.

#11 Updated by Michael Stucki over 5 years ago

  • Status changed from New to Rejected

In this case I better prefer to leave it as is. So let me close this issue.
If anyone has objections, please come up with a suggestion and I will reopen the issue...

Also available in: Atom PDF