XsrfVulnerabilityDetectionSQLInterceptor is dependent on the log level. If a customer has a setup that overrides the JIRA bundled log4j.properties, this interceptor will kick in at INFO level.

The following method of XsrfVulnerabilityDetectionSQLInterceptor does not work for GreenHopper:

line 233:
private Class getClassOfElement(final StackTraceElement element)
{
try

{ return Class.forName(element.getClassName()); }

catch (ClassNotFoundException e)

{ return e.getClass(); }

}

It will try to load the GreenHopper action class through the WebAppClassloader, which will result in a ClassNotFoundException (I assume since GH is loaded through OSGI). In return, the method is not found and the annotation check in line 161 will cause a NPE.

XsrfVulnerabilityDetectionSQLInterceptor will only fire once per request. Most paths in GreenHopper trigger an SQL UPDATE already on a setter, so before the regular action execution. That makes the problem hard to reproduce.

Path to reproduce:

1. Activate the logger for XsrfVulnerabilityDetectionSQLInterceptor in log4j.properties
2. Go to a GreenHopper view (any board)
3. Then select a different view through the main "Agile" dropdown.

This way, the Setter-Update-path is not triggered, the main action execution runs into the interceptor and a NPE is thrown.

This might potentially affect other plugins as well.