First off, this type of issue is more theoretical than anything.
jQuery allows you create HTML elements on the fly via the jQuery() method. Creating new HTML elements using this technique is common in the jQuery world since it results in more readable, jQuery-esque code.
Potential client-side code injection issues can arise if malicious input is passed to this method. Consider the following example:
$("<img src='/' onerror=alert('xss');>");
This will result in client-side code execution (mainly an alert displaying the string ‘xss’). Nevertheless, it is possible to execute arbitrary client-side code via this vector. To see this in action, check my overly contrived demo\proof-of-concept available here.
Now you should be asking yourself, what does this mean for me as a jQuery developer? In reality, not a whole lot. The main point here is that developers should always be mindful of what input is passed to the jQuery() method. Much like how developers need to be mindful of user-input in order to prevent other XSS issues and DB-level injections.
The bottom-line: never trust user-input.
Update: This issue has now been partly addressed by jQuery 1.6.3. Refer to bug #9521 for details on the fix. In short,
#id are prioritized over
The issue in general however, is still possible with selectors that are not
#id based. Take a look at my second overly contrived proof-of-concept here which uses a
.class selector instead of an