Linux | 相続・遺言なら山下司法書士事務所（長野市）

WordPressの緊急アップデートと脆弱性

たまにWordPressで重要な脆弱性が発見されることがあります。
WordPressは、利用者数が非常に多いため、どうしてもハッカーに狙われやすいという面があり、セキュリティの手を緩めることができません。

Fedoraサーバーを利用している場合、公式パッケージの更新が脆弱性公開に追いつかず、対応が遅れることがあります。
今回は緊急の脆弱性のようで、執筆時点ではFedoraパッケージではまだ対応されていないようです。

今回の内容については、piyokango氏のブログに早速情報がまとめられていました。
（参考：「WordPress Coreの脆弱性 CVE-2026-63030 / CVE-2026-60137 (通称「wp2shell」)についてまとめてみた」）

また、バージョンが対応済みかどうかを判定できるサイトもありました。
Searchlight Cyber「wp2shell: Pre Authentication RCE in WordPress Core」（脆弱性チェッカー・緩和策プラグイン公開ページ）

対応手順

Fedoraのdnfによるアップデートがまだ提供されていない場合は、Fedoraで提供されている更新用RPM（noarch.rpm）を利用して更新します。

１．バックアップの取得

作業前に、万一に備えてWordPressフォルダ全体をバックアップしてください。

tar -czf wordpress-backup-$(date +%Y%m%d).tar.gz /path/to/wordpress

また、必要に応じてデータベースもバックアップしてください。

２．更新用RPM（noarch.rpm）のダウンロード

Fedoraのパッケージサイト又はミラーサイトから、WordPressの更新用RPM（noarch.rpm）をダウンロードします。
（場所：　Information for build wordpress-6.9.5-1.fc44）

※ src.rpm（ソースRPM）では更新できませんので、noarch.rpmを使用してください。

３．RPMによる更新

ダウンロードしたディレクトリで、次のコマンドを実行します。

dnf install ./wordpress-6.9.5-1.fc44.noarch.rpm

既にインストールされている場合でも、新しいバージョンへ更新されます。

更新後は、次のコマンドでバージョンを確認できます。

rpm -qi wordpress

又は

rpm -q wordpress

４．動作確認

WebブラウザからWordPressへアクセスし、正常に表示されることを確認してください。

更新後にパーミッションやSELinuxの問題でエラーが発生した場合は、必要に応じて次のコマンドを実行します。

restorecon -Rv /path/to/wordpress

また、Apacheのエラーログも確認してください。

journalctl -u httpd

Fedoraのリポジトリで更新版が提供されるようになれば、通常どおり

dnf upgrade wordpress

で管理することができます。

生成AIは、文書添削に非常に便利なツールですが、利用にあたっては
以下の点に注意が必要とされています。

・出力内容がニュアンスによって変化し、意図と異なる結論になる場合がある
・入力データに顧客情報や個人情報が含まれるリスクがある

特に法的文書を扱う場面では、いずれも重大な問題です。とりわけ、
個人情報等を生成AIにそのまま入力することは、顧客の同意がある場合
であっても、サービス側でどのように利用・学習されるか不明であり、
安易に行うべきではありません。

そのため、法律職が個人情報を扱う場合は、生成AIサービスのうち、
入力データをインターネットに通信しない、ローカル環境（オンプレミスサーバー等）
にインストールするタイプのものを利用する方が望ましいでしょう。

こうした形態は「ローカルLLM」と呼ばれ（参考：富士フイルムビジネス
イノベーション社「ローカルLLMとは？〜」）、現在利用可能な主な構成
としては、以下のようなものがあります。

・Ollama × gemma4
・Ollama × gpt-oss
・LM Studio × gemma、Qwen 等

なお、ローカルLLMはモデルデータだけでも数GB以上の容量があり、
快適に動作させるには高性能なグラフィックボード（GPU）が必要です。
これは生成AIの推論に、CPUやメモリに加え、GPUの並列計算機能が
不可欠であるためですが、近年のAI需要拡大によりメモリ関連デバイス
の価格が上昇しており、機器調達は容易ではありません。

しかし、生成AIを業務で活用する以上、データセンター等の契約サーバー
を除き、セキュリティ確保の観点から、こうした機器類を自前で整備
する必要があります。昨今の生成AI利用には、相応の費用と手間が
伴うのが現状のようです。

Fedora43→44にアップデート

当事務所のメインサーバー（クローズド環境）では、Fedoraを採用しています。このディストリビューションは、年２回程度のメジャーアップデートがあり、時期としては大型連休前後及び秋頃です。

今回もアップデートを実施しました。手順は以下のとおりです。

sudo dnf install dnf-plugin-system-upgrade
sudo dnf system-upgrade download --releasever=44
sudo dnf system-upgrade reboot

もっとも、アップデート後は動作検証を慎重に行う必要があります。不具合が発生すると業務に支障を来すおそれがあるためです。

前々回は、Popplerの仕様変更により登記情報の変換ができなくなり、対応に相当の工数を要しました。今回はそのような問題が生じないことを願うばかりです。

セキュリティ対策として SPF・DMARC を導入

いわゆる電子メールの仕組みは，昔ながらの POP3 や SMTP というプロトコルの上に成り立っています。
とても便利な一方で，セキュリティ面ではどうしても古い部分が残っており，大量送信が容易なことから，不正な攻撃に悪用されてしまうことがあるようです。

最近では，認証情報を狙った不審メールを大量に送り続けるタイプの攻撃が増えているとの報道もあります。
（参考：日本経済新聞「世界の不審メール7億通、8割は日本標的」）

こうした状況を受けて，特に Gmail や携帯キャリアのメールでは強力なフィルタが導入されています。
しかしながら，仕組みの詳細が公開されているわけではなく，システム管理者にとっては「どこで弾かれているのか分からない」状況になることも多いのが実情です。

Gmail では，SPF レコードや DKIM，DMARC といった認証技術の導入を強く推奨しているようです。
（参考：Google「認証方法について（管理者向け）メール認証の基本を学ぶ」）

当事務所でも，外部への送信メールを一部システムで利用していることから，今回は SPF レコードと DMARC の設定を行いました。

参考にしたのは次のサイトです。

設定後，オープン側のサーバー（基幹サーバーではありません）から送信したメールについて，SPF も DMARC も「PASS」と判定されるようになりました。これにより，Gmail やスマホキャリア宛ての返信メールでも，これまでより安定して届くようになったと思います。

今後もセキュリティへの配慮を続けながら，メールシステムの安定運用に努めていきます。

↓設定実施前のgmailのメールソース

↓設定実施後のgmailのメールソース

想定外のPoppler更新で大混乱：登記情報変換の再構築記

弊所ではこれまで，登記情報等の PDF を変換する手段として，Fedora に含まれる Poppler の「pdftohtml」を利用していました。
しかし，変換時の不具合が発生したため，「pdftotext」へ切り替えることにしました。

この変更により，PDF→html に変換したうえで bash で文字操作を行っていた従来の仕組みを，PDF→テキスト（平文）へ変換してから処理する方式に改めました。

html とテキストでは性質が大きく異なります。
タグがなく，レイアウトの概念もないため，テキストの並び順や内容，さらには PDF の線の位置などから判断して精査する必要があります。

実際に確認してみると，土地や一般建物については情報の位置がほぼ一定で，それほど手間はかかりません。
一方，区分建物と会社登記はレイアウトや内容が多様であり，土地・一般建物に比べて複数のパターンに対応しなければならず，処理が複雑になりました。

さらに，テキスト精査は html を扱う場合よりも文字位置が安定せず，どうしても内容を逐一確認しながら処理する形となります。
そのため，bash の cut などの単純な文字操作では対応しきれず，変数展開を多用することになり，結果として処理速度も低下しました。

こうした調整を重ね，ようやく新しい登記情報変換システムが形になりました。
今後は，変換後のデータに誤りがないか確認しつつ，業務で安定して使えるよう整えていこうと思います。

登記情報から文字を抽出するソフトによる不具合

Fedora42 から 43 にアップデートした際，「pdftohtml」を含む Poppler が同時に 24.x から 25.x へ更新されました。
通常であれば特に問題は生じませんが，登記情報の PDF を html に変換したところ，書式が大きく変わってしまいました。

アップデート前

┏━━━━━━━━━┯━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓&#160;<br/>　　　┃専有部分の家屋番号│７１０－１　～　７１０－４４　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　┃&#160;<br/>　　　┠─────────┴─────────────┬──┬───────────┬─────┬───────────┨&#160;<br/>　　　┃　表　　題　　部　　（一棟の建物の表示）　　　│調製│平成８年７月１１日　　│所在図番号│　　　　　　　　┃&#160;<br/>

アップデート後

┏━━━━━━━━━┯━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓<br/>　　　┃専有部分の家屋番号│７１０－１　～　７１０－４４　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　┃<br/>　　　┠─────────┴─────────────┬──┬───────────┬─────┬───────────┨<br/>　　　┃　表　　題　　部　　（一棟の建物の表示）　　　│調製│平成８年７月１１日　　│所在図番号│　　　　　　　　┃<br/>

レイアウトが変わっただけでなく，アンダーバーを含む文字が取り込めなくなるなど，変換精度に影響が出ています。

これにより，申請書・委任状・各種物件データや役員データの管理で使用していた自作の変換ソフトが，文字数やタグ構造の変更にまったく対応できなくなりました。
仕様変更は避けられず，作業全体の見直しを迫られています。

そこで，変換手段を「pdftohtml」から「pdftotext」に切り替えることにしました。
ただ，「pdftotext」では登記情報特有の全角スペースがうまく変換されず，従来の「文字数で位置を特定する方法」が使えなくなりました。結果として，線やレイアウトを手がかりに判定する方式へ移行せざるを得ません。

一日でも早く状況に対応し，システムを復旧させたいところです。

Fedora42→Fedora43

２０２５年１０月２８日に Fedora 43 がリリースされたため，メインサーバー（クローズド環境）を早速アップデートしました。

手順は次のとおりです。

#事前準備
dnf upgrade --refresh
reboot -n

#ダウンロード
dnf system-upgrade download --releasever=43 --allowerasing
#(Fingerprintを確認)

#アップグレード実行
dnf system-upgrade reboot

アップグレード後，いつもどおり eFAX サーバーと Nextcloud の設定を再投入する必要がありましたが，
今回は dovecot（IMAP メール受信サーバー）で問題が発生しました。

dovecot が 2.3 から 2.4 にバージョンアップしたことにより，設定記述の方式が一部変更されています。
特に メールのパス指定 が変更されており，元の設定に戻す必要があります。

vi /etc/dovecot/dovecot.conf
mail_path = ~/mail
↓
本来のメールパス

また，「/etc/dovecot/conf.d」以下の「10-mail.conf」 などの設定ファイルが削除または無効化されていました。
そのため，必要に応じて設定を再作成・再有効化する必要があります。
再作成する場合には，記述方法がver2.3とは異なっているので注意が必要です。
（参考　Dovecot CE「Upgrading Dovecot CE from 2.3 to 2.4」）

テキスト処理で一行目だけエラー？──原因は「BOM付きUTF-8」でした

先日，あるテキストファイルを使ってコマンド処理をしようとしたところ，一行目だけがどうしてもエラーになってしまうという現象に直面しました。

リストファイルの各行をもとにコマンドを生成し，コピペで実行しても一行目だけが動かない。
不思議に思い，最終的には一文字ずつ文字コードを調査して原因を特定するに至りました。

原因は「FEFF」──UTF-8のBOM

調査の結果，一行目の先頭に「FEFF」という不可視の文字コード（BOM: Byte Order Mark）が入っていることがわかりました。
この「FEFF」は，UTF-8でBOMありとして保存されたファイルの先頭に付く特殊なコードで，Linux系OS（Fedoraなど）では扱いに注意が必要です。

なぜBOMが入っていたのか？

使用していたクラウドソフトが，スマホ表示に対応するため標準でBOM付きUTF-8形式でテキストを記憶しなければならない仕様になっていたため，Windows側のテキストアプリケーションの設定で「BOMあり」ファイルを作ってしまっていたからです。

その結果，テキスト処理スクリプトやシェルコマンドなどが，一行目を正しく認識できなくなっていたというわけです。

対処法と今後の教訓

テキストエディタで保存形式を確認

・UTF-8（BOMなし）で保存できるようにエディタの設定を見直す

最後に

一見ただの文字列ファイルでも，見えないバイト列が処理を妨げていることがあるという良い教訓になりました。
今後も，テキスト処理を行う際には，BOMの有無や文字コードの確認を忘れずに対応していきたいと思います。

同じように「なぜか1行目だけエラーになる」などの不可解な現象でお悩みの方がいれば，ぜひBOM付きファイルでないか確認してみてください。

Fedora41→42 のリリースとアップグレード

昨日，Fedora42が正式リリースされたようでしたので（参考 fedora MAGAGINE　「What’s New in Fedora Workstation 42」），メインサーバー等をFedora41から42にアップデートしました。
方法は以下のとおりです。

１．いつも通り，現状バージョンの最終アップデート

dnf upgrade --refresh
reboot -n

２．DNFアップグレードパッケージのインストール

dnf install dnf-plugin-system-upgrade

３．Fedoraの新バージョンのダウンロード

dnf system-upgrade download --releasever=42

４．GPG キーを検証します。（識別子が下記サイトと同じかを確認します）ＯＫなら［ｙ］を入力してenterを押します。

場所：　Fedora はあなたの安全を守ります

OpenPGP キー ● をインポート中:
 UserID: "Fedora (42) <fedora-42-primary@fedoraproject.org>"
 識別子: ●
 提供元: file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-42-x86_64

Is this ok [y/N]: y

５．ダウンロード後，リブートして更新

dnf system-upgrade reboot

６．各パッケージの正常性を確認します

更新後，１点問題点がありました。postfixが起動していませんでした。よって以下の設定をしています。

#古いパッケージを消す
dnf install remove-retired-packages
remove-retired-packages 41

#コンフィグファイルの更新
dnf install rpmconf
rpmconf -a
#何回かenterを求められる

「/etc/postfix/mail.cf」などが更新されて，加工前のものが「main.cf.proto」に入れられます。

そして，postfixのサービスが停止しているため，改めてスタートさせます。

systemctl start postfix

メールの送信を確認します。

#メールの送信
mail root

以下のエラーが出るため，mtaを変更

s-nail: Cannot start /usr/sbin/sendmail: executable not found (adjust *mta* variable)

alternatives --config mta

再度 mail rootを実行時メール

#メールの送信
mail root

#メールの受信
#→メールクライアントを使用

※追記　postfixの起動だけではメールの送信ができませんでしたので，alternativesを追加しました。

WordPressのアップデートができない！？SELinuxによる書き込み制限

SELinux を運用しながら WordPress を更新する際に，FTP 接続情報の入力画面が表示される 問題についての解決策をまとめました。

問題の原因

SELinux により，WordPress のディレクトリ./wordpress に対して 書き込み権限が制限されている ため，WordPress が通常の 直接更新 を行えず、FTP 接続を求めてきます。

エラーログ（ausearch の出力）からも，httpd_sys_content_t のコンテキストでは 書き込みが許可されていない ことが確認できます。

type=AVC msg=audit(xxxxxxxxx.xxx:xxxxx): avc: denied { write } for pid=xxxx comm="php-fpm" name="wordpress" dev="dm-0" ino=xxxxxxxxx scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:httpd_sys_content_t:s0 tclass=dir permissive=0

解決策

① SELinux のコンテキストを一時的に変更

以下のコマンドで，WordPress のディレクトリに書き込み権限を付与 する。

sudo chcon -R -t httpd_sys_rw_content_t .(どこか)/wordpress/

この操作で，WordPress が更新ファイルをダウンロードし，直接適用できるようになります。

② WordPress の更新を実施

管理画面から WordPress の更新 を実行する。
FTP 接続画面が表示されずに，直接更新ができるようになります。

③ 更新後、元の SELinux コンテキストに戻す

更新完了後に、本来の SELinux の設定に戻す ことで、余計な書き込み権限を解除します。

sudo restorecon -R -v .(どこか)/wordpress

これにより，WordPress ディレクトリの SELinux コンテキストがデフォルトに戻り，セキュリティが保たれます。

④ 永続的に書き込みを許可する場合（オプション）

頻繁に WordPress を更新する場合は，SELinux の設定を変更して 永続的に書き込みを許可 することもできます。（セキュリティ的にはやや劣後します）

sudo semanage fcontext -a -t httpd_sys_rw_content_t ".(どこか)/
wordpress(/.*)?"
sudo restorecon -R -v .(どこか)/wordpress

まとめ

方法	SELinux の設定	更新後に戻す必要
`chcon` で一時的に変更	`httpd_sys_rw_content_t` を適用	必要（`restorecon`）
`semanage fcontext` で永続的に許可	`.(どこか)/wordpress/` のコンテキストを変更	不要

どの方法が適切か？

🔹 厳格なセキュリティ管理が必要な場合
　✅ chcon を使って一時的に変更し，更新後 restorecon で戻す
🔹 他のアプリケーションの影響を最小限にしたい場合
　✅ semanage fcontext で .(どこか)/wordpress のみ書き込み許可

また，「setsebool -P httpd_unified 1」を有効化する方法もあるようですが，セキュリティ的にさらに劣後することになります。これについては，他サイトを参照してください。（未検証）

これらの方法で，SELinux を有効に保ちつつ，WordPress の更新をスムーズに行えるようになるでしょう。

カテゴリー: Linux