URL parameter manipulation and injection

tl/dr: Whether or not you have a reflected XSS vulnerability depends on the exact method you use to append the data. Therefore you should specifically check your chosen method to make sure it is safe. Modern javascript frameworks typically take care of these things automatically for you, but jQuery doesn't, so attention to detail is critical.

You don't specifically have to worry about the interaction between site 1 and site 2. The reason is because site 2 needs to be secure in all the normal ways anyway (use prepared queries, etc...). A malicious user wouldn't use site 1 to attack site 2 (in this case), because if they wanted to they could just go attack site 2 directly.

So the main question here is whether or not site 1 is vulnerable. To be clear, the concern would be over the possibility of a reflected XSS attack (which is what ExecutionByFork mentions in their answer). To give a simple example, what happens if a user visits this URL:

http://mysite.com?p="><script>alert(1)</script>

If the way you add the p parameter to all other links implicitly treats its contents as HTML, then you will end up injecting an actual script tag into the page, executing the attackers javascript in a classic reflected XSS attack.

So the question is: do you append the p parameter in a way that potentially treats the data as HTML (creating a vulnerability), or do you append it in a safe way? The answer to that question comes down to the specific methods you use to append the data. Let me give two examples:

Largely safe: .prop()

Using the jQuery .prop method is safe because it falls back on setting the property of the corresponding DOM node. By doing it this way there is no opportunity to escape the property context. In essence, whatever you send in to the .prop method will only ever be treated as a string, with no opportunity for execution. So code like this is safe from a reflected XSS attack:

var link = $('a').first();
old_href = link.prop('href');
link.prop('href', old_href + '?p=' + injected_data))

However this would not be safe if the user had full control of the final href (if for instance you didn't append, but instead set the href based exclusively on the user input). In that case the user could switch the link to execute javascript like so:

http://mysite.com?p=javascript:alert(1)

Which would cause a vulnerability for code like this:

link.prop('href', injected_data))

As long as you are appending data to something that is already there, this is impossible. However, if the href tag is previously empty, you can end up with a vulnerability (although it will only fire if the user clicks the link: not just by loading the page).

Of course, even this doesn't guarantee safe-ness, since potentially malicious data is hiding around in your application to cause problems. You may forget that the href now contains user data, and if some other javascript grabs the href out of a link and tries to do something with it, it may cause trouble. Also, keep in mind that this malicious data will be passed along to Site 2 when someone clicks the link, so Site 2 needs to properly secure itself (which was true before anyway, so that's not really anything you didn't already know).

Not safe: .replaceWith()

However, many other javascript methods will allow your string to be treated as HTML, which will result in reflected XSS. In fact, there are probably more dangerous methods than safe one, so you should probably verify that whatever method you are using is actually safe. Still, to pick an example, .replaceWith() will evaluate your string as HTML. So something like this would be dangerous:

link = $('a').first();
old_href = link.prop('href');
link.replaceWith('<a href="' + old_href + '?p=' + injected_data + '">click here</a>');

Your website may be vulnerable to a reflected XSS attack (It depends upon how you are setting that value and how the data is interpreted). For example, imagine if I access the following URL:

mysite.com?p="></a><script>malicious_code()</script><a href="

If your site converts this:

<a href="secondurl.com">Link </a>

into this:

<a href="secondurl.com?p="></a><script>malicious_code()</script><a href="">Link </a>

And then if the user's browser parses the updated HTML, the malicious_code() will be immediately executed in their browser. Please be aware that this is not the only method of performing XSS. Ultimately, it depends upon how your site takes the user data and adds it to the href attribute, so even if <script> tags don't work in this specific scenario, other methods easily could. Take a look at OWASP's XSS filter evasion cheat sheet for examples.

This is why it is important to make sure data coming from a user always sanitized when it is included in data that is later interpreted as code. If user input never utilized as instructions, then it's usually safe to not sanitize that data. However, be aware that injection could happen anywhere downstream. It's easy to forget data which isn't coming directly from a user may not be sanitized.

Can this compromise your server? Not directly, but it's still a gaping security hole which should be patched. Using XSS, an attacker could send you a link to execute javascript on your machine. If you happened to be logged in, they could then steal your session cookie and use it to access the wordpress site as if they were you. This would give them access to any administration panels that you normally have access to, and they could escalate their privileges from there.

Note: Another thing you should consider is how you are using the parameter that is getting passed to secondurl.com. This is another vector which might allow access to your site, as it is ultimately controlled by the user.