fix: replace os.path.join with safe_path_join to prevent path manipulation (CWE-22)

[Copilot]

49 path manipulation vulnerabilities (CWE-22) remain in v5.3.2 despite the prior safe_path_join introduction, because many call sites still use os.path.join directly.

What do these changes do

Replace every remaining os.path.join call that constructs a file-system path with safe_path_join, which canonicalizes via os.path.abspath and validates the result is within the expected base directory before returning it.

What was wrong

safe_path_join existed in pythainlp.tools.path but was not consistently used. Affected sites spanned module-level path constants, archive extraction logic, and model-loading helpers — any of which could accept tainted input (archive member names, user-supplied model directories) and silently produce a path outside the intended base.

How this fixes it

All os.path.join calls that produce file paths are replaced with safe_path_join:

File	Detail
pythainlp/corpus/__init__.py	_CORPUS_PATH constant
pythainlp/tag/unigram.py	4 module-level model path constants
pythainlp/tag/perceptron.py	4 module-level model path constants
pythainlp/parse/transformers_ud.py	local model sub-directory joins
pythainlp/translate/en_th.py	_get_translate_path return value
pythainlp/spell/words_spelling_correction.py	embeddings.npy and vocabulary.txt paths
pythainlp/tokenize/crfcut.py	CRF model path
pythainlp/corpus/core.py	get_hf_hub, tar/zip member validation, symlink target validation

For archive extraction (Python 3.9–3.11 fallback path), the previous os.path.join + _is_within_directory two-step is replaced with a single safe_path_join call that raises on traversal. Relative symlink targets are resolved by passing the archive-root-relative member dirname and link target as separate *parts directly to safe_path_join, which handles the join, canonicalization, and containment check in one step — eliminating all intermediate os.path.join calls:

# Before
member_path = os.path.join(path, member.name)
if not _is_within_directory(path, member_path):
    raise ValueError(...)
# ... and for symlinks:
rel_candidate = os.path.normpath(os.path.join(os.path.dirname(member.name), link_target))
safe_path_join(path, rel_candidate)

# After — canonicalizes and validates in one step, no intermediate os.path.join
try:
    safe_path_join(path, member.name)
except ValueError:
    raise ValueError(f"Attempted path traversal in tar file: {member.name}")
# ... and for symlinks:
try:
    safe_path_join(path, os.path.dirname(member.name), link_target)
except ValueError:
    raise ValueError(...)

Unused import os statements removed from files where os was only needed for os.path.join.

Your checklist for this pull request

• Passed code styles and structures
• Passed code linting checks and unit test

Original prompt

---

This section details on the original issue you should resolve

<issue_title>bug: PyThaiNLP version 5.3.2 still have issue about Path Manipulation</issue_title>
<issue_description>### Description

Unfortunately, PyThaiNLP version 5.3.2 still have issue about Path Manipulation

pythainlp-v5.3.2 23MAR2026 DeveloperWorkbook.pdf

This article give suggestion by Clean Path
Fortify keeps track of the parts that came from the original input. If you use any of the original input, you may still get the error.
https://www.experts-exchange.com/articles/30499/Fortify-Path-Manipulation-Issues.html

This article suggest that
Fortify will flag the code even if the path/file doesn't come from user input like a property file. The best way to handle these is to canonicalize the path first, then validate it against a white list of allowed paths.
https://stackoverflow.com/questions/12690652/how-to-fix-path-manipulation-vulnerability-in-some-java-code

Parse the input for a whitelist of acceptable characters. Reject from the input, any character you don't want in the path.

Expected results

If possible, security issue about Path Manipulation should be fixed.

Current results

There are 49 issues found about Path Manipulation.

Steps to reproduce

Run source code scan tool, such as Fortify.

PyThaiNLP version

5.3.2

Python version

3.12

Operating system and version

Windows

More info

No response

Possible solution

This article give suggestion by Clean Path
Fortify keeps track of the parts that came from the original input. If you use any of the original input, you may still get the error.
https://www.experts-exchange.com/articles/30499/Fortify-Path-Manipulation-Issues.html

This article suggest that
Fortify will flag the code even if the path/file doesn't come from user input like a property file. The best way to handle these is to canonicalize the path first, then validate it against a white list of allowed paths.
https://stackoverflow.com/questions/12690652/how-to-fix-path-manipulation-vulnerability-in-some-java-code

Parse the input for a whitelist of acceptable characters. Reject from the input, any character you don't want in the path.

Files

No response</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes bug: PyThaiNLP version 5.3.2 still have issue about Path Manipulation #1357

---

⚡ Quickly spin up Copilot coding agent tasks from anywhere on your macOS or Windows machine with Raycast.

[bact]

@copilot there are few instances of os.path.join introduced. do they necessary? do another review.

[Copilot]

@copilot there are few instances of os.path.join introduced. do they necessary? do another review.

Done in 7214d5c. The last two os.path.join instances (inside the symlink validation helpers for tar and zip) are eliminated. safe_path_join accepts *parts and canonicalises/validates everything internally, so passing the archive-relative dirname and link target as separate parts replaces the intermediate os.path.join entirely. No os.path.join calls remain in any of the modified files.

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud