Question 1

왜 LanguageTool은 카탈루냐어 문장을 대문자로 바꿀 때 타이포그래픽 아포스트로피를 직선 아포스트로피로 변경하나요?

Accepted Answer

LanguageTool의 UPPERCASE_SENTENCE_START 규칙은 이제 원래 아포스트로피 문자를 유지합니다. 원래 문장에 타이포그래픽 아포스트로피(’)가 포함된 경우, 제안된 수정은 일반 아포스트로피(')로 정규화하는 대신 동일한 타이포그래픽 아포스트로피를 사용합니다. 이 수정은 아포스트로피 유형에 대한 명시적 규칙이 활성화되지 않았거나 텍스트에 이미 타이포그래픽 아포스트로피가 사용된 경우에 적용됩니다. 최신 버전의 LanguageTool을 사용 중인지 확인하세요.

Question 2

nimbus-jose-jwt.jar에서 발견된 CVE-2023-52428 및 CVE-2025-53864 취약점을 수정하는 방법은 무엇인가요?

Accepted Answer

`com.nimbusds:nimbus-jose-jwt`를 버전 **9.37.4 이상**으로 업그레이드한 다음, 아티팩트를 다시 빌드하고 재스캔하세요. **Maven** (직접 의존성 또는 `dependencyManagement` 재정의): ```xml com.nimbusds nimbus-jose-jwt 9.37.4 ``` **Gradle:** ```groovy implementation 'com.nimbusds:nimbus-jose-jwt:9.37.4' ``` JAR이 전이 의존성으로 포함되는 경우, `nimbus-jose-jwt`를 `9.37.4+`로 강제하는 의존성 제약/재정의를 추가한 다음, 다음 명령으로 확인하세요: ```bash mvn dependency:tree -Dincludes=com.nimbusds:nimbus-jose-jwt # 또는 ./gradlew dependencies | grep nimbus-jose-jwt ```

Question 3

Short answer: I can't give you a definitive yes/no without knowing which specific CVEs your scanner flagged, but here's what I can tell you and how to assess it.

**What I know:** As of my knowledge cutoff, there are no widely known critical CVEs in the core code of Apache OpenNLP (opennlp-tools) itself. Notably, opennlp-tools 1.9.4 has essentially no transitive runtime dependencies — it's largely self-contained — so if a scanner (OWASP Dependency-Check, Snyk, Trivy, etc.) is flagging critical CVEs against it, they're often either false positives from CPE matching or coming from another dependency in your tree being misattributed.

**How to evaluate actual risk for LanguageTool:**

- **Get the exact CVE IDs** and check them against NVD and the Apache OpenNLP security page. If the CVE is against a different artifact or a CLI-only component, it likely doesn't apply.
- **Look at the vulnerable code path.** OpenNLP issues typically fall into two buckets:
  - *Malicious model files*: LanguageTool bundles its own trusted models and doesn't load user-supplied ones, so this class of issue usually doesn't affect it.
  - *Untrusted input text*: If you're running LanguageTool as a server processing arbitrary text, a DoS-style issue in tokenization/tagging could be reachable.
- **Check your LanguageTool version.** Newer releases have bumped OpenNLP; if a fix exists, upgrading LanguageTool (or overriding the opennlp-tools version in your build) is the cleanest remediation.

If you share the specific CVE IDs, I can give you a much more concrete assessment.

Accepted Answer

LanguageTool 6.9-SNAPSHOT은 opennlp-tools 1.9.4를 번들로 포함하고 있지만, 현재의 사용 방식으로는 노출이 제한적입니다. OpenNLP는 영어 모듈에서 `EnglishChunker`에 의해서만 사용되며, 이는 `/en-token.bin`, `/en-pos-maxent.bin`, `/en-chunker.bin`의 세 가지 고정된 classpath 모델을 로드합니다. LanguageTool은 사용자가 OpenNLP 모델을 업로드하거나 선택할 수 없도록 하며, OpenNLP의 사전 XML 로딩 API도 사용하지 않습니다. 따라서 CVE-2026-40682 (XXE)는 해당되지 않는 것으로 간주됩니다. CVE-2026-42027 및 CVE-2026-42440은 공격자가 번들로 제공된 모델 파일이나 classpath를 교체하거나 제어할 수 있는 경우에만 악용될 수 있으며, 검사할 텍스트를 제출하는 것만으로는 충분하지 않습니다. 유지 관리자들은 opennlp-tools 2.5.9+로 업그레이드할 계획이지만, 해당 버전은 현재 영어 테스트를 깨뜨리며 호환성/모델 업데이트가 필요합니다. 완화 조치로서 LanguageTool 설치 디렉터리와 번들 모델 파일에 대한 쓰기 접근을 제한하고, 신뢰할 수 없는 OpenNLP 모델이나 사전을 로드하지 않으며, 호환되는 업그레이드를 모니터링하십시오. 모델 파일에 대한 체크섬 검증도 요청되었습니다.

LanguageTool

주요 기능

할 수 없는 것

사용 사례

태그

시작하기

유사한 프로젝트